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Cuvânt înainte 


Apariţia calculatorului electronic în urmă cu peste 40 de ani a dus nu numai la apariţia | 


D D EEN le A E " iX EI A e 1 d 
unei noi ştiinţe ci şi la aşa zisa "criză soft". Dacă la începuturi realizarea unui calculator însemna 


o muncă de pionierat, iar costurile hardului erau preponderente în ansamblul cheltuieli 

necesare realizării şi exploatării sistemelor informatice, pe măsură ce tehnologiile de EE 
componentelor electronice s-au perfecţionat, raportul costurilor hard-soft a început să se 
micşoreze, astăzi el fiind subunitar. În timp ce costul echipamentelor a scăzut an de an, de peste 


` 100 ori, costul scrierii programelor a scăzut nesemnificativ în cifre absolute, ponderea sa ajungând 


la 90% din costul total al unui sistem de prelucrare automată a datelor. 


AST În afara progreselor tehnologice obţinute în microelectronică, la micșorarea raportului 
amintit a contribuit esenţial, începând cu anii '80, apariţia calculatoarelor personale. Construite 
pe baza unui microprocesor si a altor microcircuite integrate pe scară foarte largă si produse în 
număr foarte mare (fapt ce a dus la scăderea dramatică a costului lor), acestea au revoluţionat 
informatica, cel puţin din motivele expuse în continuare. În primul rând, nespecialistul in ^ 
informatică are acces la calculator şi deci nevoie de aplicaţii, ceea ce a generat apariţia de firme 
de soft care-au crescut peste noapte şi care produc componente soft ce se comercializează în 

“milioane de exemplare. Este binecunoscut exemplul caselor de soft americane Microsoft, Borland, 
Ashton-Tate, Lotus şi altele, inexistente în anii *70; astăzi se observă regrupári considerabile în 
plan organizajional. Marile firme producătoare de calculatoare și-au ajustat si ele politica față de 
această piaţă, fie introducând standarde hard precum IBM (linia IBM PC), acompaniate de o 
asistenţă soft adecvată, fie reorientându-şi strategiile de producere a softului. Apoi, lărgirea 
considerabilă a spectrului de aplicaţii, cu efecte tot revoluţionare în alte domenii, din care amintim 
doar birotica, tehnoredactarea computerizată şi, în perspectiva imediată, sistemele multimedia, 
au contribuit şi contribuie la impunerea calculatorului ca instrument de lucru în activitatea umană. 


Criza soft mai sus amintită provine din constatarea, simplă la prima vedere: sistemele de 
programe nu ţin pasul cu tehnologia hard. Acest lucru înseamnă cá realizarea de noi componente 
electronice. (microprocesoare în special) nu este acompaniată de lansarea simultană pe piaţa 
informatică a unor produse soft care să exploateze caracteristicile acestora, fiind necesar un timp 


` (de luni sau chiar ani de zile) pentru adaptarea produselor soft existente la noile configurații hard 


sau pentru realizarea de noi aplicaţii. În acest răstimp apar noi strápungeri hard şi procesul se 
reia, de obicei pe o scară mai mare, decalajul păstrându-se. : 


Creşterea puterii de calcul ai a dimensiunii memoriei, (interne sau externe a) 


“calculatoarelor, datorate progreselor tehnólogice, au contribuit si ele la lărgirea sferei aplicaţiilor, 


permițând abordarea unor. probleme: extrem de complexe, cum sunt previziunea vremii, 
prelucrarea datelor de teledetecţie oferite de sateliții artificiali sau prelucrarea informațiilor 
aferente prospecţiunilor geologice marine. 


„ Considerentele expuse conduc la creşterea importanţei metodologiilor de realizare a 
produselor program, în ideea industrializării activităţii de elaborare a programelor. În ultimul timp 
se foloseşte termenul “ingineria programării", datorat asemănării dintre fazele întâlnite în ciclul 

` de viaţă al unui program (specificare, proiectare, implementare, întreţinere) cu cele intilnite la 
realizarea produselor industriale. Există argumente pro şi contra folosirii acestui termen. Astfel, 
activitatea de programare are un pronunţat caracter abstract în fazele sale iniţiale, de multe ori 
modelarea matematică jucând un rol important, ceea ce nu este specific ingineriei, care este prin 
“excelenţă o activitate pragmatică. Pe de altă parte, prograniul realizat poate fi multiplicat în 


DH 


D 


oricâte exemplare, fapt ce-l aseamănă cu producţia industrială de serie. Aici putem menţiona $i 
o deosebire: odată programul realizat, multiplicarea lui în oricâte exemplare este extrem de facilă 
nefiind nevoie de materii prime, subansâmble şi de manoperă ca în cazul producţiei industriale, 
ci doar de suport (magnetic) pentru copiile sale. 


În formarea tinerilor informaticieni este importantă dobândirea unor cunoștințe şi 
deprinderi de a realiza produse program complexe, cum sunt componentele unui sistem de 
operare sau aplicaţiile de pestiune. Pentru aceasta este, necesară respectarea unei discipline de 
lucru şi cunoașterea unei metodologii adecvate de proiectare şi realizare â acestor. produse. 
Profesiile consacrate în elaborarea softului sunt cele de analist și programator, iar un bun 
specialist trebuie să posede cunoștințe solide în ambele direcţii. După opinia noastră, în activitatea 
de instruire se pune un mai mare accent pe învăţarea tehnicilor. de programare propriu-zisă 
(numită şi codificare), deci pe formarea programatorilor, acordându-se o pondere mai mică 
disciplinelor legate de analiza şi proiectarea sistemelor soft, adică formării analiştilor. Fără teama 
de a gregi, considerăm că învăţarea limbajelor de programare trebuie acompaniată de studiul şi 
însuşirea metodelor moderne de analiză şi proiectare a aplicaţiilor soft. 


Scopulprincipal al lucrării de față este de a prezenta metodele de programare cunoscute 
în prezent şi discutate în literatura de specialitate. Nu vom fi preocupaţi de măsurarea 
complexităţii unui program ci doar de modul în care el poate fi obținut. Expunerea începe cu 
trecerea în revistă a metodelor clasice de elaborare a programelor, dezvoltate în anii '60-70. 
Tranzitia de la metodele clasice la cele moderne este realizată în capitolul II, dedicat definirii 

- noţiunii de produs program si în care se precizează factorii ce concură la stabilirea calităţii 
softului. Există două categorii de factori de calitate, unii externi procesului de elaborare a softului, 
sesizati de utilizatorul produsului, iar ceilalți interni acestui proces, care sunt influenţaţi esenţial 
de metodele de analiză și proiectare folosite. Dintre factorii interni, un loc aparte îl ocupă 
modularitatea softului, care la rândul ei este o- premisă a reutilizării. Următoarele două capitole 
sunt dedicate programării dirijate de date, numită şi programare bazată pe obiecte, respectiv 
programării orientate pe obiecte. Clasele de metode sunt prezentate gradat, urmând evoluţia lor 
firească. Noţiunile si conceptele prezentate sunt însoțite de exemple simple, în care s-au folosit: 
limbajul Pseudocod în descrierea algoritmilor, un limbaj de specificare informal în descrierea 
tipurilor abstracte de date şi limbajul Turbo Pascal pentru codificare. Capitolul V conţine 
prezentareaunor module reutilizabile, ce se constituie într-un set de instrumente (toolbox) pentru - 
realizarea interfeţei utilizator, iar în ultimul capitol sunt expuse și explicate pe scurt 32 de 3 
"paradigme", "proverbe", "re i" sau "sfaturi! utile proiectanților şi programatorilor. 


Cluj -Napoca, iulie, 1994, 
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CAPITOLUL 1 


METODE CLASICE DE ELABORARE A PRODUSELOR PROGRAM 


1.1. INTRODUCERE 


Apariţia primelor "calculatoare electronice a constituit un salt uriaş în direcția 
automatizări activităţii umane. Calculatoarele au fost folosite la început prin programarea lor 
în limbaj mașină. Această programare, era o activitate dificilă care a dus repede la apariţia 
limbajelor de asamblare $i apoi a celor evoluate. Cu toate că saltul făcut a fost uriaș, apariţia 
limbajelor evoluate nu a dus automat și la îmbunătăţirea radicală a productivităţii în 
programare, S-a observat că productivitatea muncii în programare este încă scăzută 
aproximată la circa 2000 linii sursă pe om într-un an. 

„Creşterea continuă a costului scrierii de programe se datorează unor factori obiectivi. 
Cel mai important considerăm că este creşterea complexităţii programelor elaborate pentru 
problemele tot mai complicate rezolvate astăzi cu ajutorul calculatorului. Apoi, este necesară 
adaptarea programatorului la condiţiile reale existente. Programele destinate supravegherii 
şi/sau conducerii în timp real a unor procese industriale trebuie să pornească de la realitatea ` 
locului de muncă respectiv cu care sunt obișnuiți munditorii din acel'loc şi nu este permisă 
simplificarea condiţiilor reale pentru a se ajunge la programe mai simple. Un al treilea factor 
ce contribuie la creşterea costului constă în schimbarea programului iniţial, schimbare 
datorată şi ea: unor factori obiectivi. Astfel, lumea reală se află într-o continuă mișcare, 
ducând la modificarea condiţiilor în care s-a presupus că lucrează programul. Este necesar 
ca acesta să se adapteze noilor condiţii. Apoi există dorinţa firească a beneficiarului de a . 
obţine mai multe rezultate cu ajutorul calculatorului şi în consecință este necesară modificarea 
programului iniţial pentru a satisface dorința acestuia. De asemenea, schimbarea configurației 
hard poate duce la schimbări în program. : 


Creşterea performanţelor calculatoarelor, răspândirea acestora şi folosirea lor în cele 
mai diverse domenii de activitate a dus la creşterea complexităţii problemelor rezolvate cu 
calculatorul. Acesta a devenit un mijloc indispensabil multor activităţi umane, iar unele dintre 
ele ar fi fost imposibil de rezolvat în absenţa lui. În acelaşi timp unele aplicaţii trebuiesc 
realizate contra cronometru, programele corespunzătoare trebuind să fie realizate într-un 
timp limitat, insuficient pentru a putea fi realizăte de o singură-persoană. 

Astăzi se simte nevoia elaborării unor produse-program complexe, la care trebuie 
să participe mai mulţi programatori. In [Vad85] produsele-program sunt clasificate în: simple 
(până la 1000 de linii sursă, realizate în câteva luni), de complexitate medie (până la 10000 
linii sursă şi elaborate de 1-5 programatori, realizate în cel mult doi ani), complexe (până la 
100000 linii sursă şi elaborate de 5-20 de programatori în 2-3 ani), foarte complexe (până la 
1 milion linii sursă, elaborate de 100-1000 programatori în câţiva ani) şi programe aproape 
imposibile (câteva milioane de instrucţiuni, elaborate de peste 1000 de programatori într-un 
timp ce poate depăşi 10 âni de zile). i xe : 

* Ca exemple de programe complexe cunoscute tuturor menţionăm compilâtoarele, 
sistemele de gestiune a bazelor de date şi sistemele de operare in general. 


“Trecerea de la programarea individuală la'programarea în echipă a necesitat 
“schimbarea stilului de muncă, respectarea unei discipline în programare, găsirea unor 
' modalităţi adecvate de comunicare între programatori, precum şi a unor modalităţi adecvate 

de specificare a problemelor. Termenul programare este folosit aici în sens larg, înțelegând 
prin el întreaga activitate depusă de la enunţul unei probleme până la obținerea unui program 
entru rezolvarea çi: Aşa cum vom vedea, această activitate conține mai multe faze, una dintre 


ele fiind și programarea propriu-zisă, numită şi implementare, 


De fapt, însuşi E ; EE 
istorie a laf apt, însuşi termenul de program (programare) a suferit schimbări în scurta 


UV E enc Prin anii "60 prin program se înțelegea rezultatul scrierii unui algoritm 
un limbaj de programare. Din cauza creşterii complexităţii problemelor rezolvate, astăzi 
E rezolvarea unei probleme adesea vom concepe un sistem de mai multe programe. În 
[ "SU programarea este definită ca fiind activitatea de elaborare a unui produs. program. 
Activitatea de programare. implică următoarele subactivităţi: specificarea, proiectarea, 
implementarea, documentarea şi întreţinerea produsului program. 


i Prima dintre metodele de programare utilizată a fost programarea modulară. Odată 
cu apariţia limbajului FORTRAN în 1956, care avea posibilitatea folosirii subalgoritmilor în 
programare şi compilarea separată, apare și prograriarea modulară. Tot compilarea separată 
a dus la apariţia bibliotecilor de subprograme. Programarea modulară constă în 
descompunerea unei probleme complexe în subprobleme, pentru fiecare subproblemă 


elaborându-se câte un subalgoritm. Algoritmul de rezolvare al întregii probleme va fi obținut 
prin asamblarea acestor subalgoritmi (module). 


Părintele programării structurate este profesorul E.W. Dijkstra de la Universitatea 
Tehnică din Eindhoven, Olanda: El arată [Dah72] că se pot ob(ine programe mai bune fárá 
instrucţiunea GOTO: calitatea unui. program este invers. proporţională cu numărul de 
instrucțiuni GOTO pe care le conţine. E du 
Fundamentarea teoretică a programării structurate se datoteste apoi lui Bohra şi 
Jacopini [Boh66] care au demonstrat. cá sunt suficiente trei structuri de calcul, secvenţa, 
“selecţia şi itera(ia, pentru descrierea oricărui algoritm... ' : 


În 1971 Wizth [Wir71] continuă fundamentarea teoreticáa metodelor de programare, 
definind procedeul detalierii algoritmilor în paşi succesivi (stepwise refinement), iar in 1972 
` H.D.Mills [Mil 75] foloseşte conceptul de funcţie pentru modelarea unui algoritm. 


Există astăzi cercetări referitoare la demonstrarea corectitudinii programelor. Deşi 
nu există rezultate care să permită demonstrarea automată a corectitudinii unui produs- 
program. complex, aceste cercetări au contribuit la instaurarea unei munci disciplinate în 
activitatea de programare. p 


Mulţi specialişti consideră astăzi că limbajele viitorului vor fi limbaje de specificare 
a problemelor, urmánd ca pe baza specificárii să se realizeze o programare automată. 


Le P 
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12. FAZELE REZOLVĂRII UNEI PROBLEME CU CALCULATORUL , 


Diversificarea utilizării calculatoarelor, pătrunderea acestora în cele mai diverse 
activităţi umane, au condus la luarea în considerare a unei mari varietăţi de probleme din ce 


în ce mai complexe care pot fi rezolvate cu. ajutorul calculatorului. 


“Rezolvarea unei probleme cu ajutorul calculatorului presupune parcurgerea 

următoarelor faze: —- SE 
“2 precizarea cerinţelor beneficiarului, 
- specificarea problemei; — XC et 

- proiectarea algoritmului de rezolvare a problemei; 
- programarea propriu-zisă (implementarea); 
- testarea produsului obținut, pia 
- exploatarea şi întreţinerea programului; | 


- redactarea documentaţiei fiecăreia din fazele enumerate, 
Aceste faze constituie ciclul de viaţă al programului. 


na 


De foarte multe ori, atunci când beneficiarul discută cu executantul despre problema 


V 
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care trebuie rezolvată, acesta dă un enunţ vag, incomplet, dacă nu chiar inexact sa hiar 

contradictoriu, pentru problema de rezolvat. Urmează mai multe discuţii, uneori întinse în 

timp, în urma cărora se ajunge la un enunț relativ complet şi exact al problemei Executantul 

are sarcina de a obține de la client enunţul cât mai exact al problemei, cát şi condiţiile în care 

se va executa programul, pe ce calculator, cu ce spaţiu de memorie internă $1 externă, etc 

Aceasta este prima fază din activitatea pe care o va depune executantul, fază numită definirea 
“problemei și terminată cu menţionarea scrisă a cerinţelor clientului. 

Dialogul client-executant trebuie să se termine cu un enunţ clar al cerințelor 
clientului. O situaţie frecvent întâlnită constă în interpretarea diferită dată aceleiaşi propoziţii 
de către cele două tabere. Deşi au fost de acord cu enunţul problemei, pot exista în acest 
enunț propoziţii care pentru executant înseamnă ceva iar pentru beneficiar înseamnă altceva. 
Este necesar ca în urma acestui dialog fiecare propoziţie să reprezinte acelaşi lucru pentru 

„ ambele tabere, neexistând ambiguităţi în formularea și interpretarea ei. 


. Urmează faza a doua, specificarea problemei, în care cerințele clientului sunt 
analizate atent şi reţinute sub forma unui document care precizează cât mai exact ce trebuie 
să facă programul cerut. Este foarte important ca această fază să se termine cu specificafia 
corectă a problemei. Se recomandă verificarea atentă a acestei specificafiiastfel ca eventualele | 
contradicții să fie înlăturate încă din această fază. 


După stabilirea specificaţiilor, urmează modelarea matematică şi căutarea unei 
metode de rezolvare a problemei. Uneori sunt posibile mai multe moduri de rezolvare, caz 
în care se va alege metoda considerată cea mai potrivită scopului urmărit. Modelarea 

- matematică şi alegerea unei metode de rezolvare- se -îmbină aproape întotdeauna cu 
conceperea algoritmului, fiind greu sá,se separe una de cealaltă. Activităţile de mai sus 
constituie ceea ce numim proiectarea programului. În această etapă echipa de proiectare va 
defini structura produsului ce trebuie realizat (componentele, modulele), structurile de date - 
şi algoritmii folosiţi. Vor fi definite toate modulele şi interfețele dintre ele şi se va da 
specificaţia fiecărui modul în parte. 

... Pe toată durata proiectării trebuiesc menţionate în scris toate deciziile luate, întrucât 
este posibil ca ulterior să fie necesară o reproiectare si deci, să se tevină asupra acestor decizii. 
Documentaţia realizată este necesară în primul rând pentru următoarea fază a ciclului de 
viaţă al programului, implementarea. De asemenea, în faza de întreţinere a programului este 
posibilă modificarea unor module, modificare în care sunt necesare să fie cunoscute şi aceste 
decizii. E bine ca proiectarea să fie astfel făcută încât să permită o întreţinere cât mai uşoară. 
O anume schimbare nu trebuie să provoace schimbarea tuturor modulelor ci doar câteva 
module să fie afectate. Eventual pot fi necesare câteva module noi, dar majoritatea modulelor 
să fie folosite fără nici o modificare. 

Uneori specificarea: inițială nu este suficient de exactă. Bencficiarul îşi. poate 
completa ori preciza cerinţele chiar pe timpul proiectării. Depinde de proiectant dacă în urma 

„acestor completări sau modificări trebuie să ia totul de la capăt sau, datorită unei proiectări 
flexibile, uşor de adaptat şi modificat, analistul se poate adapta-usor noii situații. — . 

Schimbarea. specificaţiilor problemei pe parcursul proiectării în cazul în care la 
realizarea programului participă o echipă formată din mai multi programatori trebuie adusá- 
imediat la cunoştinţa tuturor. SC 

. Fazaa patra, implementarea sau codificarea, constă în traducerea algoritmului într- 
un limbaj de programare. Evident, prima decizie ce trebuie luată constă în alegerea limbajului 
de programare în care va fi scris programul. De multe ori se vor folosi mai multe funere 
pentru aceastá activitate. De exemplu, pot exista unele module a căror scriere:se poate face 
numai în limbajul de asamblare. ' 


E : : " : : : A i dem 
Urmează faza a cincea, testarea programului elaborat, care uneori pune în evid 
erori grave de programare, 'erori care au dus în unele situaţii la refacerea (parţială sau 
` integrală) a activităţilor anterioare. Sigur că este de dorit să nu se ajungă la astfel de situaţii 


^ 


1 


D 


KR 


şi, dacă proiectarea si implementarea au fost făcute corect, în faza de testare nu ar trebui să . 
întâlnim erori. În [Sch90] testarea nu este considerată o, fază separată, după scrierea 
programului, ci o activitate continuă pe toată durata proiectării, implementării şi întreţinerii 
programului respectiv. Suntem de acord cu acest punct de vedere. Mai mult, considerăm că 
testarea clasică a programelor este deja înlocuită cu activitatea de verificare a programelor, ' 
activitate extinsă la întreg ciclul de viață al acestora. Ea îmbină metodele tradiţionale de 
are a programelor cu metodele matematice de demonstrare a corectitudinii unor părți din 
am. ; 


prg 


* 


2 


Următoarea fază din viaja programului constă în exploatarea propriu-zisă a acestuia, 
fază în care execuţia se face cu date reale. Această activitate se întinde în timp şi cere adeseori 
schimbări în program, motiv pentru care este cunoscută sub numele de întreţinerea 
programului. Este faza cea mai costisitoare şi cea mai importantă din viaţa produsului. Toată 
activitatea de realizare a programului trebuie să țină seama de acest fapt şi să fie astfel gândită 
încât să se permită modificări în ceea ce face programul cu un număr minim de modificări în 
textul acestuia. Întreţinerea presupune şi actualizarea documentaţiei prin precizarea tuturor: 
modificărilor făcute. 


: à À i. Ea c abora: i document care arată ce trebuie să - 
actul de naştere al programului. Ea cere elaborarea unui document ` uie să 
facă programul. Acest document, care trebuie să reflecte exact cerinţele beneficiarului şi să 


EE SE 
-© "Dándu-se un text format din cuvinte Separate printr-un caracter spațiu sau Newline, 
să se convertească într-o secvență de mai multe linii după următoarele reguh 
1) Fiecare linie conține o parte din text ce se termină cu un cuvânt; 
SA Fiecare linie conţine cât mai multe cuvinte din text; 
3) O linie are cel mult MAXPOS caractere, ` 


e că ma este enunțată pecialist în domeniu, ca nu este core, tá. ' 
: ate cá problema este enunțată de un specialist în domeniu, e: 
Erorile din SE lui Naur au fost observate; de mai mulţi autori. O primă sous 3 Ai 
semnalată în recenzia făcută de Leavenworth [Lea70], iar London Dat semnaleaz 


/ SE ; : A AC ` ia 


trei erori. Goodenough şi Gerhart: [Goo75] au scris specificaţi i 

1. Gc h j C pecificatia problemei într-u 
patru ori mai lung decât al lui Naur. Evident au făcut-o cu multă atenţie şi cu SE a 
înlătura orice eroare. Cu toate acestea Meyer [Mey85] a găsit în s 9 3 


ra l ate ac écificația a 
greşeli şi a dat o nouă specificaţie într-un limbaj matematic. ` Gees put SS m 
eci pentru o problemă relativ mică, specifica(ia scrisă de specialisti î i 
S d lem. ti în domeniu a 
conținut destule erori. Ce se întâmplă pentru o problemă mult mai ge 
dut se intám complexá la ă 
o echipă de programatori obişnuiţi? 3 SS SE 


Specificarea unei probleme poate fi tăcută atât în limbaj natural cât şi în limbaj 
matematic, Specificaţia scrisă într-un limbaj natural are şansa mai mare de a conţine 
oi taci omisiuni sau ambiguităţi, în timp ce specificaţi în limbaj formalizat este mai greu 

urmărit. 


` Această fază trebuie să se încheie cu un document (scris) de specificare. El trebuie 
să reflecte exact sarcinile produsului ce se va realiza, care sunt datele de intrare si care sunt 
rezultatele cerute; de asemenea, la ce restricţii este supus programul. 
a „Se recomandă ca specificaţia făcută unei probleme să fie analizată atent cel puţin de 
- către o persoană diferită de autorul specificaţiei. La verificarea specificării unei probleme 
complexe se recomandă să lucreze o echipă din care vor face parte reprezentanţi atât din 
- partea executantului cât şi.din partea beneficiarului. S : : 


1.4. PROIECTAREA PRODUSULUI 


Scopul acestei faze este de a preciza cum sunt realizate cerinţele beneficiarului, care 
sunt algoritmii folosiţi şi structurile de date cu care se lucrează. Deosebim: . 

- proiectarea de ansamblu, a întregului program; : 
_- proiectarea detaliată a fiecărui modul. . 
Rezultatul, acestei etape este numit proiect (de ansamblu sau de detaliu). 


În proiectarea de ansamblu se decide structura produsului pornind de la specificaţii. = 
Acest produs se descompune în module, precizându-se scopul fiecărui modul şi interfaţa 
dintre module. Interfața dintre module precizează datele care sunt transferate între module, 
așa cum va reieşi din descrierea subalgoritmilor (vezi secţiunea 1.4.2). Proiectarea de detaliu 
se referă la fiecare subalgoritm (modul) în parte. - EI RR ES ; 


În descrierea algoritmilor se folosesc mai multe limbaje de descriere, dintre care cele 
mai des folosite sunt^ EE is 
| limbajul schemelor logice; ee 
'x'/-unlmbajpseudocod.. 2 e EE : 
- Considerăm cunoscut limbajul” schemelor: logice $i nu-l vom folosi aici decât cu scopul 
precizării semanticii unor propoziţii sau structuri de calcul. : 


D 


: GG E normal propoziţiile unui algoritm se execută secvențial, în ordinea în care 
- apar ele în text. În schemele logice execuţia urmează sensul indicat de săgeată, putând avea. 
loc reveniri în orice punct din schema logică. Din acest motiv se poate ajunge la o schemă 
logică foarte încâlcită, greu de urmărit şi descifrat. „o CS. 
^. Rezultă importanţa compunerii unor scheme logice structurate, In care drumurile de - 
la START la STOP să fie uşor de urmărit şi să'conţină structuri bine precizate. S 
` L4. Limbajul PSEUDOCOD `; ES 
D à d Ar SIN W " $ : ` 
^ i k puri D " EN H 4 * H OU ` d care. va 
i “În continuare vom folosi pentru descrierea algoritmilor limbajul Pseudoco à 
`- fi definit in cele ce urmează. Ținând seama că găsirea unui algoritm pentru rezolvarea unet , 
- ^ probleme nu este întotdeauna o sarcină simplă, că în acest scop sunt folosite-anumite metode 


7 


- 


unde valoare aparține multimii D v [nedefinit]. 


A A m arche ază mărimile cunoscute în problemă. Se subintelege că SE variabile sunt inifiahzate 


E care lé vom descrie în paragrafele următoare, limbaj 
poziții: propoziţii standard şi propoziţii nestandard 

propoziţiile nestandardsu M en à Sd 
nefinisate, asupra cărora 
prin faptul cà î 


ul Pseudocod are două tipuri de ; 
i nesta Aşa cum se va arăta mai târziu, 
nt texte care descriu părţi ale algoritmului încă incomplet elaborate 
d urează să se revină, Ele sunt deosebite de propoziţiile standard 
neo înot, : NIA (vedete : E Ure 
Tw | p intotdeauna cu semnul '*' si se termină cu "," ca orice propoziție în limba 
Pe lângă aceste propoziţii standard si ard, î i i 

a > pro : şi nestandard, în textul algoritmului vom mai 
introduce propoziții explicative, numite comentarii. Pentru a le distinge de celelalte propoziții, 
comentariile vor fi închise între acolade. Rolul lor va fi explicat puțin mai târziu. 

. . Propoziţiile standard ale limbajului.Pseudocod folosite în această lucrare, corespund 
structurilor de calcul prezentate în figura 1.4.1. 


. “Structura secvenţială este redată prin concatenarea propozitiilor i 
sau compuse, ale limbajului Pseudocod, care vor fi executate în GE Se ees. 
Propoziţiile simple din limbajul Pseudocodsunt DATE, REZULTATE, ATRIBUIE şi apelul 
de subprogram. Propoziţiile compuse corespund structurilor alternative şi repetitive. 
-- ..., Propozitile standard DATE şi REZULTATE sunt folosite în faza de specificare a 
problemelor. În etapa de programare propriu-zisă acestor propoziţii le corespund într-un 
limbaj de programare instrucţiuni de intrare-ieşire. | 


d e £ CF 
a) strüctura - - . b) strucfura ` — . c)structura 
[7 secvențială- - 565 alternativă . = ~ repetitivă 
e Figura 14.1. Structurile elementare de calcul 


e Propoziția standard DATE se foloseşte pentru precizarea datelor inițiale, deci a 
- datelor considerate cunoscute în problemă (numite şi date de intrare) si are sintaxa: 


M 
E 
S 2 


“unde listă” «conține toate. numele variabilelor a căror valoare iniţială este cunoscută. În ` 


` general, prin listă se înţelege o.succesiune de elemente de acelaşi fel despărțite prin virgulă. 
viU Zare variabila joacá:un 19l central in programare este binc sá definim acest 


- concept. Variabila defineşte: o márime care îşi poate schimba valoarea in timp. Ea are un 


nume şi, eventual, o valoare. Este posibil ca variabila încă să nu fi primit valoare, situație în 
E că ea este nciniţializată. Valorile pe care le poate lua variabila aparţin unei 


“mulţimi D pe care o vom nuri domeniul variabilei. În concluzie vom înțelege prin variabilă 


^^ uipletul e o. 


Ee (nume, domeniul D, valoare) WS 


"Aşa cum s-a spus, prin propoziția DATE se precizează acele variabile: care 


Di Suc QM EM Uca olet iA i 


cu valorile cunoscute corespunzătoare lor. 


Pentru precizarea rezultatelor dorite se foloseşte propoziţia standard ; 


REZULTATE listă ; S 


în "listá" fiind trecute numele ariabilelor care marchează i 
y conțin rezult D 
| i ; ( L ) atele cerute in 


Blocului de atribuire dintr-o schemă logică îi corespunde în Pseudocod propoziţia 
standard cÉ e i ; 


[ATRIBUIE] v : = expresie ; Y 
Accastá propoziţie este folosită pentru a indica un calcul algebric, al expresiei care urmează 
după simbolul de atribuire ": = "si de atribuire a rezultatului obținut variabilei v. 

. Prin scrierea cuvântului ATRIBUIE între paranteze drepte se indică posibilitatea 
omiterii acestui cuvânt din propoziţie. El s-a folosit cu gândul ca fiecare propoziţie să înceapă 
cu un cuvânt al limbii române care să reprezinte numele propoziției. Atunci cînd vom scrie 
succesiv mai multe propoziţii de atribuire vom folosi cuvântul ATRIBUIE numai în prima 
“propoziţie, omijándu-l în-celelalte. = e CN DIA 


DE 


AE “Foarte mulţi algoritmi execută anumite calcule în funcţie de satisfacerea unor 
"condiţii. Aceste calcule sunt redate de structura alternativă prezentată în figura 1:4.1.b, căreia 


“îi corespunde propoziţia Pseudocod ` > ae cw one Ncc 
DACAcondATUNGLAALTFELBSEDACÀ i 


QU A A PAD 


1, 


sau varianta redusá a ei, ` 


"DACĂ cond ATUNCI A SFDACÀ: EE SS 


folosită în cazul în care grupul de propoziţii B este vid. 2 M Ee E 
E Structura repetitivà prezentată în figura 1.4.1.c este; redată în limbajul Pseudocod 


D 


CAMP cond EXECUTĂ A SECÂT. 


grupului de 
- grupului A ar 


- programare. mbá udocod : | 
: APretractionile uiui limbaj de programare trebuie să transmită acelea; 


LI 


„corespunzătoare: > . ^ 


TI Sp 5e zm XU SC. 


. und imi ii | ; 
Set? este suma primilor n + 1 termeni iar r, este restul corespunzător. El (ine seama că 
ulr, este mai mic decât ultimul termen t, al sumei s,. 


Specificaţia algoritmului în limbajul Pseudocod este: pd 


-DATEe; [e»0)] a 
REZULTATE ve; { aproximarea seriei cu o eroare .< € 
decir- |e-ve| < e) ` 
d A 


Variabilele auxiliare folosite în descrierea algoritmului sunt: 


:1- precizează ultima fracţie adunată; 
_t- este valoarea acestei fracţii. 


í 


4 
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Algoritmul propriu-zis este descris în continuare: 

(Algoritmul de calcul al numărului e cu precizia el $ 

ATRIBUIE ve: =2.5; t: =0.5; 153; — 
x CATTIMP t7 € EXECUTĂ. S SE 


E d Ee 
EE SE 


 SECAT ` 6 
Algoritmul prezentat este general, el putând fi folosit indiferent dacă dorim. să 
- calculám numărul e cu precizia admisă de calculator la reprezentarea unui număr real, sau 
cu o precizie mărită. Programarea (codificarea) algoritmului va tine seama de acest lucru. 
Dacă dorim precizia obținută prin reprezentarea obişnuită a lui e într-o locaţie de memorie, 
atunci vom transcrie relativ uşor acest algoritm într-un program. Dacă însă dorim să calculăm 
numărul € cu 1000 cifre exacte atunci algoritmul va trebui transpus într-un program care să 
efectueze toate câlculele în consecință. De asemenea, reprezentarea numerelor reale în 
calculator va trebui făcută cu această precizie. Ea nu mai poate fi făcută într-o singură locaţie 
de meimorie. O soluţie constă în a reprezenta un număr real ca vector cu 1004 componente, ' 
- primele cifre după virgulă din reprezentarea zecimală a numărului real subunitar. S-au 
"prevăzut patru cifre în plus pentru ca o eroare pe poziţia 1005, la fiecare termen al sumei să 
"nu afecteze primele 1000 de cifre. Într-adevăr, dacă n termeni se vor aduna si fiecare are o 
eroare pe poziţia 1004 (cel mult 5) atunci eroarea totalá este cel mult SEU 


055 po aros < 5000 * 10 = 0:56 1079. 


întrucât numărul n al termenilor ce sé adună este determinat din condiția OO CU .In 
-atest caz.sunt necesare subprograme pentru efectuarea operaţiilor ti şi e-* t cu precizia 
menţionată. ` VeRO. NIS Ud : 


"^ 


“Pe lângă propoziţiile Pseudocod deja prezentate sunt utile si alte propoziții, care ar: 
utea fi descrise prin intermediul structurilor elementare de calcul, a căror folosire măreşte 
claritatea algoritmilor şi scurtează scrierea. ~ j g 


L è 


D 


Astfel, avem o generalizare a structurii alternative la structura selectivă 


SELECTEAZĂ i DINTRE ` ? 
vI: Al; 
V2: A2; | 


< vni An 
SFSEL 


structură echivalentă cu următorul text Pseudocod: 


DACĂ i=vl ATUNCI A1 SFDACĂ ^ 
DACAi-V2ATUNCIA2SFDACÀ ` 


DACÁi =vn ATUNCI An SFDACĂ  . f 


* 


“În descrierea ynultor Rigo se întâlnește structura repetitivă condiţionată 
posterior, : 


REPETĂ A PÂNĂCÂND cond PREE 


D 


` structură echivalentă c cu: SA 


Camp not(cond) EXECUTĂ A SFCÀT 


> Ea cere execuţia necondiționată a lui A şi apoi Verificared condiţiei "cond". Va avea loc 
„repetarea execuţiei | lui A până când condiţia devine adevărată. Această structură este numită 
structura repetitivă conditionata posterior deoarece prima execuție a blocului A este 

c necondiționată. VESN d 


GA 


o altă propoziție c care cere execuţia repetată a unei i secvenţe A este propoziția 


PENTRU « Ce "din EXECUTĂ A SFPENTRU ` 
Ea definește structura repetitivă cu un număr determinate de execuţii ale SE de 
propoziţii A si este SS cu secvența: . iz o cai ntre e An 


= t x SG n 3 D 
SE REPETA afla e UE 
A RUE ALAS dx p c S 4 

SEH =c+p 

PÂNĂCÂND pon pos sau dies is D SFREP 


is. descriereai unui algoritm deosebim următoarele activităţi importante: 
. - specificarea problemei; — — 
AA descrierea metodei alese pentru SE problemei; : 
- precizarea denumirilor ; ŞI Ee EE EE 
BE descrierea BM propriu-zis. ERN 


‘Astfel, dată ni se cere să calculam radicalul de ordini? dia X, în partea de specificare ` 
E DCN T vom „menţiona: ` SEN AE 


"se dà un număr M holan Pai care OMNE sá Sigg. 
($e eere să SE un alt fum pozitiv e astfel mestrer ? ' 


125 


prin nici 
specifi 


Pentru un informatician este clar că un astfel de număr nu se poate găsi în general 

un procedeu finit. Este însă posibil să găsim o aproximare oricât de bună a luiz. Deci 
carea făcută nu este corectă, neputând găsi un algoritm care să rezolve problema în 

torina enunțată. Vom modifica această specificaţie, cerând să se calculeze r aproximativ cu o 

eroare ce nu depăşeşte un număr real eps oricât de mic. Ajungem astfel la 


Specificaţia problemei este: 


DATE eps,x; (epsxeR, eps >0şi x20) ' : 
REZULTATE r; ( |r-rad(x) | < eps) 


unde prin rad(x) am notat radicalul de ordinul 2 din x definit în matematică. 
Urmează să precizim metoda de rezolvare a 
t 


două posibilități de a calcula per: i ; 
- ca limită a unui şir (definit printr-o relaţie de recurenţă) convergent lar, . 


problemei. Se ştie că există cel puţin vU 


- prin rezolvarea ecua(ieir —x. 7 x s 
Précizám că-l vom calcula pe r rezolvând ecuația =x prin metoda coardei si a tangentei. 
Această metodă constă in micșorarea repetată a intervalului [a,b] care confine rădăcina r la 
intervalul [a',b'], aşa cum se poate vedea în figura LA , 


t d ZI x 
UE yon ` t z 
i GA * ~ CG Le A Ger? 
| n2 yi t^ 
CH i 
apa A pi 3 m 
d. e oe t 
i 
` ge 
` 
* 


ae: SUA Figural42. Grafic pentru metoda coardei şi a tangentei. | 
OU Variabilele folosite in descrierea algoritmuluisunt: . (o S 

/ aşib ="capetele intervălului în care se află rădăcina; ^ ^... 

-r mijlocul intervalului (a,b) în momentul în care b-a < €, | —— ^ ^ 


1 
PELA. S > 


e edeti valoarea Cabala: pp ace r ec nete Le iP AAAA PESSE vC 
m „ Algoritmul propriu-zis este descrisîn continuare: e 


peto uei EE UL C RR 
EAT IRA A REPETA 5 ES AT SEN Se SE SE i Tx S : - 
005. 7. *Atribuie lui a abscisa punctului de intersecție a axei OX cu coarda ce. 


ki 


uL e punctele (af(a)) si(bf(b):- —. ^ s. ; * 

` SE EE SE GE d axei OX cu tangenta în 
EES ` punctul (b,f(b)) dusă la graficul funcţiei HE: ; 
UI DANA CAND Base SERPI AR ee d VE e N 


e E iza SEE a Ma eat a i ae a e ezită foarte Bes 
if T textul de mai sus apar trei propoziţii nestandard care sugere í [oai i 

S A ce EERTE întreprinse. Prima stabilește inter alul inițial în care se află inm ce 
t depinde de mărimea lui x: (1) când x este mai mic decát 1 sau (1x) in caz cohtrar.] eci ea. 


“i „se va transcrie în propoziţia standard 


DACĂ x< 1 ATUNCI ATRIBUIE a: —x; b: 
. ALTFEL RULE a: —1; b: 
SFDACĂ 


` Celelalte două propozitii nestandard se vor transcrie în propozițiile standard 


ATRIBUIE a:=E,; 
ATRIBUIE b:- "E 


unde: 
E, este expresia care dá abscisa punctului de intersecţie a axei OX 
unește punctele (a,f(a)) şi (b,f(b)), iar ; B 
E, este expresia care dă abscisă punctului de intersecţie a axei OX cu fans pu în, 
| punctul (b;f(b)) dusă la graficul funcţiei f(t) = ex 
` Orice "absolyéni de Deen. ar trebui s să poată deduce singur aceste expresii. Se ajunge SG 
următoarea variantă finală: 


: LInigializeazà pe a şi b ) ou GE S 


SE DACĂ x<1 ATUNCI ATRIBUIE a: zem db y P 

UAE ALTFEL ATRIBUIE gb por MU T 
Us SEDACĂ i ; : AE dE 
REPETĂ . HQ ON EU AL e 


"ATRIBUIE a:=E,; - 
¿£ abscisa mus de SE a axei, Oxs tu coarda ce unește punctele 


fa ia) şi (b.5)] 
=E; 


X SE punctului de intersecție a axei OX. cu utangentai în a punctul e, Tor 

„dusă la graficul funcției f(t) = De -x tf SUC UNIS 

s PÁNÁCAND b-a« e SFREP. : isp S US E CUT TS 
ATRIBUIE D (E E EE 


ATR 


Proiectarea algoritmilor ŞI iplo uu lor sunt i douk- activităţi distincte în 
rezolvared problemelor cu ajutorul calculatorului. Avantajele folosirii limbajului Pseudocod ~ 
E in timpul proiectării algoritmilor" constau în faptul că permit programatorului să-și îndrepte 
i complet atenţia asupra logicii rezolvării problemei şi să uite “de restricţiile i impuse de limbajul 

^^. de programare si calculatorul folosit. În această fază este SE o analiză atentă a 
pones in vederea Een unui algoritm, uc proiectat ; SE 


SE De asemenea, ' proiectarea algoritmülui permite, evitarea = duplici unui grup de 
rU e d insiructiuni in mai multe părți ale programului. Identificarea unui astfel de grup, permite ` 
YU o „definirea: lui ca un noir SE E folosirea, acestui subalgoritea, de ori câte ori este. 


aote 142. Subalgori tor 


e 


blema Sa a „unei i probleme: mai complexe C: 


4 poate apare ca subpro 
Orice problem pons ap Să FORO acest caz un subalgoritm pentru algoritmul 


ra ul de rezolvare a. 
ee e SE C. În Pseudocod folosirea unui subalgoritm în FER algoritm 
i Pe fafo apelna s acest noo. E Weg EES să 
d e Kee Dé X Gë ck" "NN 
d ! E y y l ; 19 


 . ordonate descrescător, adică:, —— ` SE SE E 


unde "nume" 
Această listă 


este numele subalgoritmului apelat iar "par este li at = 
1 t I pa' éste lista parametri i 
confine toate datele de intrare ŞI toate datele de ieşire dii phun 


Pentru a defini un subalgoritm vom folosi propoziţia standard 


SUBALGORITMUL nume (pf) ESTE: 


unde "nume" va fi numele subalgoritmului definit; iar "]p£ 
SHE SEIT sunt forma[i din variabilele care marche 
atele de ieşire (rezultatele obținute) ale subalgoritmului. Această propoziti urmatá 
D a D D D z e est 
textul efectiv al subalgoritmului, care precizează calculele E rezolvării ride 


corespunzătoare. Descrierea se va încheia cu cuvântul SFSUBALGORITM Analog, pen 
^ D LLIS Li H șa 
a marca începutul descrierii unui algoritm vom folosi propoziţia standard: ` e 


ALGORITMUL nume ESTE: t 


pi va conţine lista parametrilor 
ază datele de intrare (cunoscute) şi 


e 


iar pentru sfârşitul descrieriiunui algoritm vom folosi cuvântul SFALGORITM sau SF-nume. 


: Íntre lista parametrilor formali din definiţia subalgoritmului şi lista parametrilor 
actuali propoziţia de apel trebuie să existe o corespondenţă biunivocă. Deşi denumirile 
variabilelor din cele două liste pot să difere, rolul variabilelor care se corespund este acelaşi. 
Mai exact, parametrul formal şi parametrul actual corespunzător trebuie să se refere la. 
aceeaşi entitate, trebuie să aibă aceeaşi semnificaţie. Nu greşim prea mult dacă considerăm 
„că în timpul execuţiei algoritmului cei doi parametri devin identici = = = 


2 "Pentru exemplificare să considerăm următoarea problemă: dirigintel unei clase de 
elevi doreşte să obțină un clasament al elevilor în funcţie de media generală. În plus, pentru 
fiecare disciplină în parte doreşte lista primilor șase elevi. > >- : 

- În rezolvarea acestei-probleme este necesară găsirea ordinii în care trebuiesc tipáriti 
elevii în funcţie de un anumit rezultat: nota la disciplina'j", sau media generală. Am identificat 
prin urmare două subprobleme independente, referitoare la: 

(1) ordonarea unui şir de numere; —— — 
(2) tipărirea elevilor clasei într-o anumită ordine. 


x Prima Subproblemă se poate specifica astfel: 


i Re : 
» Dändu-se n 


umerele Sun, ..., X, găsiţi ordinea 0,,0;,...,0,, în care aceste numere devin 


XD eua Pr 


Pentru rezolvarea ei vom da un. subalgoritn ORDINE în care intervin trei parametri formali: 
„= n, numărul valorilor existente; ^ = — - | 

- - X, vectorul qc e z bs Ge * 5 ; SC 

` - O, vectorul indicilor care dau ordinea dorita. , AI NE , 
Pami doi parametri marchează datele presupuse cunoscute, lar altreilea, rezultatele calculate — . 


SUBALGORITMUL ORDINE(n,X,O) este: ` SE 
PENTRU i: = 1n EXECUTA o; =iSFPENTRU | N 
EEN 
S Ai PENTRU j: = 10-1 EXECUTĂ 
DACĂ Saa 


/ 


SE 


ATUNCI ATRIBUIE t: o; 


D = Opi; 
Hat: je m t; 
inv: = 
SFDACĂ ; 
S SEPENTRU 
PÂNĂCÂND inv = OSFREP : 
SESUBALGORITM 


A doua subproblemá se poate specifica astfel; 


Dându-se ordinea 0505.40, à elevilor clasei, numele a mediile acestora, să se ` 
tipărească numele si mediile primilor k elevi în ordinea specificată, 


Subalgoritmul TIPAR, dat în continuare, este o soluție a acesteia: 


SUBALGORITMUL TIPAR(k, NUME, O) ESTE: 
PENTRU i: = 1,k EXECUT 
* Tipăreşte datele elevului de rang o; 
SFPENTRU . 
SESUBALGORITM 


Variabilele folosite pentru problema dată sunt următoarele: 
` - n reprezintă numărul elevilor clasei; 

- m este numărul disciplinelor la care elevii primesc note; 

- NUME este vectorul care reține numele elevilor: „NUME, este numele elevului eu. 
numărul de ordine i; 

- NOTE esté matricea notelor elevilor, având n linii şi m coloane; NOTE, este nota 
elevului cu numele NUME, la disciplina cu numărul de ordine j; NOTE; 

SE A m coloana a j- aa acestei matrice ŞI reprezintă Bote siio la disciplina 


e - MEDII este vectorul mediilor generale. : 


n3 


Algoritmul se dă în continuare: S dU C Le. St 
ALGORITMUL CLASAMENT ESTE: TSR S 
"DATE m,n; EE 
"NUME, i=1,1, M PE Cos 
NOTE, j= Uni ea, 
PENTRU i i= XECUTĂ Sg calculează media generală a T e 
SE IE $:20; IJ elevului dë , 
PENTRU j:=1,m EXECUTĂ S; = Store sire 
- ATRIBUIEMEDH;-SA ` — 
„0 SFPENTRU a 
Er SSCSEPENTRU: -LmEXECUTA ASE A AIEO 
RD E CHEAMA Genen NU 
is CHEAMÁTIPAR(G(NUMEO) — 
. SFPENTRU NS 
CHEAMĂ ORDINE(aMEDIRO); : es NAMENS eC PS SE 
"CHEAMĂ TIPAR(n,NUME, o) SON E Scop M: 


AR ua SFALGORITM | 


; S A 2 Pop 
n DCN Si NA? 


1.5. IMPLEMENTAREA 


, Implementarea (codificarea, sau programarea propriu-zisă) este procesul traducerii 
algoritmului obținut în urma proiectării într-un limbaj de programare existent în sistemul de 
calcul în care se va folosi produsul. Ea este realizată fie de un singur programator, fie de o 
echipă de programatori. Este bine ca implementarea să fie făcută de o singură persoană, lucru ` 
posibil pentru produse mai puţin complexe. Dar nu putem aștepta 20 de ani ca un singur 
programator să termine un produs complex. În acest caz munca în echipă devine obligatorie. 
SEN Alegerea limbajului, sau a limbajelor de. prògramare este prima etapă din 
implementare. Ea se impune numai dacă pe calculatorul pe care se va folosi produsul realizat 
sunt disponibile mai-multe limbaje de programare (adică sistemul lor de operare conține 
. programe translatoare pentru respectivele limbaje) şi dacă această alegere nu a fost deja 

stabilită printr-o' dorinţă expresă a beneficiarului. 

La prima vedere implementarea nu ridică probleme deosebite, ea însemnând doar 
traducerea algoritmului în limbajul de programare ales. Evident, cel. care face această 
traducere trebuie să cunoască foarte bine limbajul de programare, dar şi limbajul de descriere 
a algoritmului, Există însă anumite decizii pe care programatorul trebuie să le ia, sunt ânumite 
părţi pentru care traducerea în limbajul de programare utilizat nu este banală. 

, Ca exemplu de implementare, în secţiunea 1.11 se transcrie într-un program Pascal 
algoritmul de lucru cu fişiere, prezentat în aceeaşi secțiune. Se poate compara algoritmul 
prezentat acolo cu programul. care urmează şi urmări detaliile care în algoritm nu sunt 
prezente... SE xS ; aie a dece 
` Implementarea este adesea realizată de o echipă de programare. Evident că munca 
în această echipă trebuie organizată, membrii echipei trebuind să colaboreze între ei si să-şi ` 
comunice anumite decizii luate pe parcurs. În literatura de specialitate sunt menționate două 
organizări posibile: RER 

„- abordarea democratică; 

- echipa programatorului şef. 


Abordarea democratică este descrisă prima dată de Weinberg [Wei71]. Într-o echipă 
democratică un programator îşi încurajează colegii să-i găsească erori în modulele lui. Erorile 
nu sunt văzute ca erori ale unui individ ci ca erori ale întregii echipe. S-a observat că o astfel 

"de abordare dá rezultate mai ales la problemele dificile. Se 


“Echipa programatorului gef este formată dintr-un programator şef,2-4 programatori 
şi uri secretar. Programatorul şef are sarcina de a coordona munca celorlalți membri ai echipei .- 
şi de a realiza comunicarea dintre aceştia. Nu există o comunicare directă între membrii 
echipei ci numai o comunicare prin intermediul programatorului şef. Tot acesta are sarcina 
de a programa părţile cele ma giae El are nevoie de ungajutor ales dintre ceilalți 

ri, care să-l poată înlocui la nevoie... AU ANIM : A 

POE Rolul SE echipei este unul major. Spre deosebire.de ceilalți programatori 

"care au sarcina exclusivă de a-şi progrâma modulele lor, acesta are sarcini SE De la 

munca obişnuită de secretar, el este implicat în toate aspectele programării, find in eh is 

om priceput în sistemul de. operare pe care se lucrează. După Baker [Bak72] e m ja i 

listarea textului sursă, documentarea programului, compilarea si link-editarea module S 
execuția programului cu date de test. Deci secretarul echipei este o persoană competentă 


"toate aceste direcţii. Sigur că el avea un rol foarte important atunci când suportul de intrare” 
al programelor sursă era pe carte t 


ee: EEN 
Je perforate şi că acest rol s-a diminuat în ultimii ani. Cu 

- toate acestea multe dintre sarcinile menţionate mai sus rămân în sarcină secretarului echipei. 

| S zat prin metoda "echi matorului şef", în [Sch90] 
realizat prin metoda "echipa programatori s ve o. 

SE E York Times' a fost realizat in 22 de luni, printr-o muncă 


se arată că proiectul ziarului "Nev 1 izat în stat din 83000 lini sursă 
echivalentă cu cea a 11 persoane timp de un an de zile. us enero (2 M onus dec 


şi a avut un succes deosebit, cu foarte puține grese 


săptămîni, alte 25 în primul an și încă una singură in următi Y Sue, is 
realizat de o echipă de experti de la IBM. g mátoarele 20 luni). El a fost însă 


ntr-o situaţie obișnuită este greu de format o asemenea echipă. Este destubde greu ' 


de găsit echipa în ansamblu, dar si un şef de echipă pri ât î 
pă priceput atât în programare cát si 
organizator. De aceea se recomandă înlocuirea şefului de echipă cu doi Ze gis 
- unul specialist în programare, responsabil asupra aspectelor tehnice, fiind liderul echipei; 
- altul priceput în organizare. : 
Existá mijloace soft care ajută programatorii în: îm : i 
i i j plementare: Dintre acestea 
enumerăm editoarele de texte, compilatoarele, depanatoarele şi mediile de programare în 
general. | 


1.6. CORECTITUDINEA PROGRAMELOR ` 
x Un program este corect dacă el satisface specificaţiile problemei. Nu ne interesează 
câtă memorie foloseşte acest program, din câte instrucţiuni este compus, sau cât timp de 
execuţie necesită. Cu alte cuvinte, un SA este corect dacă pentru acele date de intrare 
care satisfac specificaţiile problemei rezultatele obţinute în urma execuţiei sunt corecte. 


'Pentru orice program P deosebim trei tipuri de variabile, pe care le vom grupa în trei 

„vectori X, Y şi Z. Componentele vectorului X desemnează variabilele de intrare, deci datele 

presupuse cunoscute în problema rezolvată prin programul P. Componentele vectorului Z 

sunt variabilele care reprezintă rezultatele cerute de problemă. În sfârşit, componentele 

vectorului Y sunt variabilele de lucru, care notează diferitele rezultate intermediare necesare 
în program. S ER 


pentru a preciza datele pentru care problema are sens. e (X) se numeşte predicat de intrare 
sau preconditie. Pentru acele valori ale lui X pentru care predicatul este adevărat problema 
are sens, pentru celelalte nu are sens să executăm programul P. ` i 


| ` Între rezultatele Z ale problemei şi datele iniţiale X (cunoscute, în problemă) există 
anumite relaţii. Vom reda aceste relaţii prin predicatul de ieşire Y(X, Z), numit. şi 


. postcondi(ie. Acesta este corect pentru acele valori a şi b ale vectorilor X şi Z pentru care. 


rezultatele problemei sunt b în cazul când datele inițiale sunt a si este fals în caz contrar. Deci, 
dacă executând programul cu datele iniţiale a obținem rezultatele b' şi (a,b?) este fals, acest. 
fapt este un indiciu că rezultatele obținute în program nu sunt corecte.. > 


Spunem că cele două predicate, predicatul de intrare ș(X) și predicatul de ieşire 


Y(X,Z), constituie specificaţi problemei. Se subinfelege că pentru a cunoaste accastá 
specificaţie trebuiesc cunoscuți şi vectorii X şi Z. Us DIE RETO TE 


1 


“O problemă nu are sens pentru orice date de intrare. Von folosi predicatul (X) - 


-  Astfel, dăcă în problemă se cere să se calculeze radicalul de ordinul 2 (notat pririr) 


dintr-un: număr real pozitiv x, specificaţia problemei este dată prin predicatele:- ~ 
K WEZ). 


- Această specificaţie este corectă pe 

“Numărul real r este in. general transcenx 
„aproximativ. Deci nu există procedeu finit pr putem 
un program care să aproximeze Oricât de bine pe 7, şi va treb 


cendent şi nu poate fi reprezentat în calculator decât 


ui să adăugăm acest lucru la 
enunţul problemei, care devine: se cere să se calculezer cu o eroare absolută maximă e dată. 
În această situaţie vectorul de intrare este X = (xe) iar specificaţia problemei va fi: 


j A 
CO E 


WE 


"=x" s : z S: = - z S SE > : = iur £s (postconditia) 
tru un matematician, dar nu şi pentru un programator. ` 


prin care putem-calcula pe r. Putem construi însă ` 


-"x>0şie>0"; 


e): 
VQGZ): "|P-x| <e". 


, Nu putine sunt cazurile în care execuţia i intră î iclu infinit, deci 
tine r programului intră într-un ciclu infinit, deci 
nu se mai termină. Este un caz nedorit, care trebuie evitat în programare. 


Referitor la corectitudinea programelor dăm următoarele definiţii: 


Definiţia 1.6.1. Sx 
Spunem că programul P se termină în raport cu predicatul de intrare (X) dacă 


pentru orice valoare a = (a,,a7,..., a.) a vectorului X pentru care predicatul Q este 
adevărat, execuţia lui P se termină. 


„Definiţia 1.62. : Ed : 
$ l Spunem că programul P este parțial corect în raport cu specificațiile problemei dacă 
: pentru valoarea a pentru care predicatul ẹ (a) este adevărat şi execuția programului 
* se termină cu rezultatele b — P(a) atunci (a,b) este adevărat. ` 


"Definiţia 1.63; |^: — 7 : 
"Spunem că un program P este total corect în raport cu specificațiile problemei dacă 
programul P se termină şi dacă el este parțial corect în raport cu aceste specificaţii. 


SE Există mai multe metode de deinonstrare a corectitudinii unui program. În 
continuare vom prezenta metoda aserţiunilor inductive datorată lui Floyd [Flo68]. ` 


$ Metoda cere alegerea unor-puncte în schema logică, numite puncte de tăietură. Se 
„va alege cel puţin un punct de tăietură în fiecare buclă, un punct de tăietură la începutul 
schemei logice (după blocul de citire) şi un punct de tăietură la sfârşitul (înaintea blocului de - 
tipărire a rezultatelor) schemei logice. : : 


În fiecare punct de tăietură se alege un predicat invariant. În punctul de tăietură de 
intrare predicatul invariant este p(X), iar în punctul de tăietură de ieşire predicatul invariant 


š este YZ). 


; - Pentru o pereche (ij) de puncte de tăietură pot exista mai multe drumuri de la i la 
j. Fie'a-un astfel de drum cu proprietatea cá el nu conține un alt punct de tăietură. Vom nota 
prin R,(X;Y) predicatul care ne dă condiţia ca să se parcurgă acest drum şi prin LE, 
` funcţia care dă transformarea variabilelor intermediare Y la traversarea drumului a. 
- Schematic, putem reprezenta notaţiile făcute astfel: + SE E 


+ 


Si cum pi, 
RSA EE GES E S x 3 J D 


Acestui drum i se asociază condiţia de verificare. 


Un | Ges) SE x "er (OC) AR) = PEY) 


Teorema LOL: |: | ^ SENSUM i ; : 
` Dacă toate condiţiile de verificat sunt adevărate atunci programul P este partial 
corect în raport cu specificaţiile e(X) si Daf | 


A “Floyd [Elo67] demonstrează următoarea teoremă: 


H AS 


? 
SE > 2 Ca exemplu de demonstrare. a corectitudinii unui program să consider ăm următorul . 


A 


algoritm de calcul al celui mai mare divizor comun a două numere date: 


= OIM) CMMDC1(n1,n2,d) ESTE: 
n 
ATRIBUÍE 3 Er (A: eis nleN, n2eN) 
o 
CÀTTIMP (dai) si (i70) EXEC E: : 
DACĂ d>i AURA d: UE CE Pg uU GLAS 
. ALTFELi:=i-d 
SEDACÀ 
SFCAT 
REZULTATE d; au Close 
SFALGORITM 


V(X,Z):- d=(n1,n2)} 


Variabilele folosite, grupate in cei trei vectori X, Y, Z sunt: 
X = (n1, n2), yo (d, D şi Z = (d). 


Drumurile polibile ta în acest algoritm sunt: «1 = AB, «2 = BB şi «3 = BC, iar condițiile de 
ES a acestor drumuri sunt: ; 


Belt = (dzi) şi (î>0); ; 
si Ray Y) = (dzi) si (î>0); 
eORQQQGY) = nu K(d»i) şi 1» 0)] iw. dei) squid 0). 


Transformárile pe aceste drumuri sunt date de: 


EH = (aln); 
M f. Dë Y) = Dacă d iatunci en altfel 1 (did); 
S GON 7 r6. 


Corespunzător acestor drumuri avem ureăloarele EE de verificare: ; 


Eck SE şi (04n2) = ( (nl, n2) = (nl, 82) ya 
(d,i) = (n1,n2)) si (d+i) si (1«0). - D AA 2 
(a) a (ai A en. DIY QUAL 
: « i- n1,n2 
Gu = (65) - (0182) si (G=) sau (70) - -(d- (192). 


Se poate verifica uşor că toate aceste condiţii Sunt adevarate. . 
Feng a demonstra terminarea pepe vom Se nojiunca de: mulțime 


convenabilă. EE 


- O mulţime este conven 
z descrescátor infinit. SE 


Td Exemple de mulțimi comvenatilesu sunt mulţimea numerelor vate Ncurelajia" «" 
$i mulia NxN cu ordinea lexicografică: S | 
mi, n1) « (m2,02) dacă (m: < <m) sau (m1 = -m) si i (ni « D 


rminarea oritmului va trebui sii demonstrám. că anumite 
E alg un că la trecerea prin schema mas (algoritm) 
á gius scad. 


1.64. Sa Acte e E, Boi MA 
Definiția s abilă dacă ca este pariat orian si nu conține nici un şir - 


TERM a demo 


loc. Aceste condiţii spun 
Ru cedi soen ja altul valogile unor funcţii în SE convenabi 


253 


xn 


Întrucât nu putem construi un şir (infinit) descrescător rezultă că nu vom trece de la un punct 
de tăietură la alt punct de tăietură de o infinitate de ori, deci execuţia este finită; cu alte 
cuvinte algoritmul se termină. Prin urmare, în punctul de tăietură i se alege o funcţie u. : D 

X Dy ^ M, iar condiţia de terminare pentru drumul a este: EE pă 


VXVY (00 ARSQGY) - UEN > u(QGr QGY) ) 


; ; În cazul în care s-a demonstrat parțial corectitudinea şi P,(X,Y) a fost predicatul 
invariant în punctul i, condiţia de terminare pentru drumul æ care duce de la punctul i la 
punctul j se poate lua: i 


VXVY (POGY) AR,QCY) - at > ura QC) ) 
Pentru algoritmul CMMDCI avem trei puncte de tăietură, pentru care alegem: 


uj(X,Y) = 2*n1 + 2*n2;. 
WEI =d ie EX 
YX, slk ; 
iar condițiile de terminare corespunzătoare acestor drumuri sunt: 


pis ub«n2)A02-0) Aia eo EE 
Ta = (Pa/(d1)A(0) = d+i>d)sau (PpA(d-« DA» 0) dii); Ș 


Se poate verifica că toate trei condiţiile sunt adevărate pentru n1 >0, dar T este 

. falsă dacă n1 =0, întrucât d ia valoarea 0 şi inegalitatea i > i este falsă. În acest caz drumul «2 
- este parcurs de o infinitate de ori, deoarece variabilele d si i nu-şi modifică valorile la 
parcurgerea acestui drum. Pentru a obţine un algoritm total corect este necesară modificarea 
algoritmului CMMDCI astfel încât să nu sé intre în drumul a2 dacă d=0.Obţinem următorul 
algoritm total corect: ` ` l `; ER 


ALGORITMUL CMMDC2(n1,n2,d) ESTE: 

DATE n1,n2; ` SC : : SS ` 
xir M RRAS ; i { Punctul A: e(4)::= nleN,neN) 
/— DACĂnI=0ATUNCI ATRIBUIE dn i50 | — SE 
ie ALTFEL ATRIBUIE d: - n1; i: = n2; | 
SEDAC A TARN X 


. — CATTIMP (dži) şi (î>0) EXECUTĂ EE : 
EE: S E Punctul B: Pp: = (dii) =(n1,n2) p 

DACĂ d>i ATUNCI d:=d-i . rcm oa tt EM 

PAKES ALTFEL E= S 

LUSPDACÁ- EE S RE 

SFCAT : SOS SAR ta | Se 

E EE Ree, Ee d= (n1,n2)) 

cis REZULTATE pc e 9 S NO A aa SENE 

„SFALGORITM ` 


SE - O'buná parte din demonstrarea corectitudinii unui program poate fi automatizată. - 
Astfel, scrierea condiţiilor de verificat, în ipoteza că sunt date predicatele invariante, poate Dr 
automatizată. De asemenea, demonstrarea automată a condiţiilor de verificat este posibilă. ` 

"Ceea ce nu se poate automatiza este descoperirea predicatelor invariante, care trebuie .- 
"furnizate de proiectant, Sor Sr eS ae ESSO ne eal 

d Această ultimă cerință impune proiectantului respectarea unei discipline în ` 
programare, Foarte probabil că aceste predicate invariante sunt sugerate de ser icaţiile 


: D ed j ; ^ dëi N E D d D 
i E ; f sx 


variabilelor. Deci este necesar ca fiecare variabilă să aibă epica cap 
M VETE să aibă semnificaţia ei şi să ; x 
în scopuri diferite. (1a ei şi să nu fie folosită 

-> Gnes [Gri85] spunea: Proiectarea programului şi demonstrarea corectitudinii lui trebuie 
făcute în paralel. Într-o astfel de proiectare convingerea programatorului că a conceput un 
algoritm corect crește, iar scrierea predicatelor invariante reduce numărul sët în 


programare. De asemenea, dacăs-ar încerca demonstrarea corectitudiniial 


` MOOBOXTUR n oritmilor descriși 
multe erori ar fi descoperite şi eliminate în faza de proiectare. i bii 


: 1.7. TESTAREA SI DEPANAREA PROGRAMELOR 


Testarea programelor este activitatea prin care programatorul observă comportărea 
programului în urmă execuției lui cu date de test. Evident, primul lucru urmărit este 
corectitudinea rezultatelor obținute în urma execuţiei programului, cu datele de test folosite 
Dar se va urmări şi dacă programul are alte caracteristici ca; utilitate, siguranţă în funcţionare, 
robusteţe, performanţă. Este beneficiarul mulţumit de rezultatele care se obțin și de forma 
sub care suht prezentate? Sunt ele obţinute în timp util? 


^ ^ 


Datele de test sunt date de intrare alese astfel încât dacă datele iniţiale ale problemei 
sunt aceste date de test atunci se cunosc rezultatele problemei. Executând programul cu 
aceste date ar trebui să ajungem la rezultatele cunoscute. Corectitudinea rezultatelor în aceste 
execuţii nu demonstrează corectitudineaprogramului în general. Testarea însă pune adeseori 

în evidenţă erori făcute în diferite faze ale programării. 

În privința aceasta dám un citat din Dijkstra [Dij76]: Testarea programelor poate fi un. - 
mijloc eficient de a indica prezenţa erorilor, dar din păcate, nu şi un mijloc de a demonstra 
. absenţa lor.. JE 5 j 

“Cu toate cá ea nu demonstrează „corectitudinea programului. testarea, măreşte 
certitudinea corectitudinii lui şi este deocamdată singura metodă practică de certificare a 
programului. Ar fi de dorit demonstrarea apriori a corectitudinii programului, dar rezultatele 
cunoscute în prezent în această direcţie nu sunt aplicabile programelor complexe, 

Scopul testării programelor este depistarea şi eliminarea erorilor. Acest lucru este 
făcut prin execuția programului cu date de test, pentru care se cunosc dinainte rezultatele (sau 
cel puţin se ştie ceva: despre ele) şi se obăervă rezultatele obținute în urma execuţiei. În cazul 
când rezultatele obţinute în urma execuţiei nu sunt cele aşteptate se vor căuta şi elimina 
_ erorile. Activitatea care urmăreşte descopcrireacauzelor erorilor şi înlăturarea lor se numeşte 

depanare. . <. 3 CE 4 i 1 


Se pune problema alegerii datelor de test si à numărului de execuţii ce trebuie făcute ` 
pentru a putea considera că programul nu are erori: Numărul tuturor seturilor de date de 
intrare posibile este teoretic infinit chiar $i pentru probleme simple. Deci nu poate fi vorba 

- de o testare exhaustivă. Stabilirea datelor de test se. poate face cel puțin pe două căt 
- ţinând seama de specificatia problemei; poteca 
- ţinând seama de textul programului. SS E SESS REA 
Aşa cum va rezulta din cele ce urmează, cea mai bună cale este una mixtă, în care sunt 


combinate aceste două posibilităţi. - 


La testarea după specificaţiă problemei, stabilirea datelor de test se face analizând 
specificaţia problemei. Se recomandă stabilirea datelor de test ținând seama ge Geen 
asupra datelor de intrare şi de specificaţia asupra datelor de ieşire. Această metodă de testare 
este adecvată problemelor simple. In cazul unei ptobleme complexe aplicarea ei- este 
imposibilă datorită numărului foarte mare de cazuri posibile, cam ar trebui AE : 

/ problema noastrá a fost 'descompusá în subprobleme mai mici, invizibile in specilicație ga | 
căror testare este mai simplă. Privind programul ca o cutie neagră nu SE mai ține aa le 
. aceste subprobleme. Totusi, testarea dupá spec icaţia problemei I ămâne o metodă uta in 


testarea modulelor. 


27 


z 


s „Testarea după textul programului ține seama, pentru a stabili datele de test, de 
instrucţiunile care trebuiesc executate. Considerând că algoritmul este descris printr-o schemă 


: logică, o execuţie a programului înseamnă parcurgerea unui drum de la START la STOP în 


această schemă. Dacă la această execuţie rezultatele obţinute sunt corecte probabil că textul. - 
algoritmului pe acest drum este corect. Ar trebui să verificăm toate blocurile schemei logice 
şi mai ales toate drumurile de la START la STOP posibile. Cu observaţia că în cazul a două 
drumuri ce diferă doar prin faptul că conţin o anumită buclă de n,; respectiv n; ori le vom 
-considera echivalente între ele. Dintre toate drumurile echivalente între ele vom testa un 
singur drum, altfel am avea o infinitate de drumuri de testat. 

„_În concluzie vom alege pentru fiecare drum un set de date de test, numărul 
execuțiilor fiind egal cu numărul acestor drumuri. Dacă toate execuțiile au dat rezultate 
corecte programul se consideră testat. Dacă însă la o singură execuţie am depistat erori, ` 
corectarea lor a modificat textul algoritmului şi testarea trebuie reluată pe toate drumurile 
afectate de această schimbare. : 2 X 

- Pentru un program complex, deci pentru o schemă logică cu un număr foarte mare 
de drumuri START-STOP, testarea ar fi o activitate complexă, constând dintr-un număr 
foarte mare de execuţii. Încă un motiv pentru a practica programarea modulară, caz în care 
testarea se tace asupra unor module mai mici şi asupra interfeţei dintre ele, aşa cum se va - 
menţiona mai jos. ; ; SE 2 

: Stabilirea datelor de test după textul programului are şi unele dezavantaje. În primul 
rând, programul poate fi incomplet şi să nu corespundă specificaţiilor. Pe drumurile existente 
el este corect, dar lipsesc drumuri care, conform specificaţiilor, ar trebui să existe. Lipsa 
acestor drumuri este o greşeală gravă care nu va fi descoperită de datele de test care ne duc 
-doat pe drumurile existente. Din această cauză se recomandă o testare mixtă. : S 
În textul unui program există și drumuri moarte, pe care nu se poate merge oricare 
ar fi datele de intrare, deci nu putem găsi date de test corespunzătoare acestor drumuri. 
Adeseori aceste drumuri scot în evidenţă erori prin simpla analiză a textului. Astfel, în 
succesiunea de propoziţii Pseudocod MN UE E S 
X 


DACĂ 2 ATUNCI o 
"DACĂn>3ATUNCI A SFDACĂ i 
SFDACĂ ` 


. grupul A este inaccesibil oricare ar fi valoarea lui n. Este însă foarte frecventă eroarea de 
` omisiune a unui caracter; în cazul nostru tastarea numărului 2 în loc de 20, ceea ce schimbă 


complet sensul textului Pseudocod de mai SUS, Ne 


Adesea este imposibil să se execute programul cu toate datele de test stabilite. În 
acest caz apare problema alegerii acelei submulțimi din aceste date care să aibă şansa maximă 
de a depista erorile prezente în program. Testarea minimă care trebuie făcută constă într-un 

“număr de execuţii a programului care să ne asigure că fiecare instrucţiune din program a fost 


executată cel puţin odată. Ea. înseamnă mult mai puţine execuţii decât toate drumurile 


"“START-STOP. - 


` — Există date de test care ne duc pe un anumit drum fără a depista erori existente în 


E instrucţiunile întâlnite şi alte date de test care, depistează aceste erori. Încă un motiv pentru 


“care se recomandă o testare mixtă. -.. nS SS EE E 
; Ca ordine de folosire a datelor de test în timpul testării, in [Sch90] se recomandă mai 
întâi testarea după specificaţii si apoi testarea după textul programului. ` d d 


Esté necesară şi testarea robusteţei programului, care înseamnă buna lui comportare . 

“Ja date de intrare intenţionat greșite, pentru care problema nu are sens. Unele programe intr , 
' 4n aceste condiţii în ciclu infinit, altele se termină cu erori de execuție. Un program ro E n 
trebuie sá fie afectat de datele de intrare eronate. Comportarea cea mai normală în astiel de 


* M i h 


situaţii ar fi semnalarea unor mesaje de eroare corespunzătoare 


Laun produs program complex testarea este o activitate mult mai complicată. Este 
necesară o testare separată a fiecărui modul în parte, o testare a interfeţei dintre module si 
o testare a produsului în ansamblu (testarea de integrare). 2; 


_ Testarea de integrare se referă la funcţionarea programului realizat în ansamblu 
După ce fiecare modul în parte a fost testat şi corectat, deci în ipoteza că fiecare modul în 
parte este corect, e necesar să se verifice comportarea globală a programului. În această 
situaţie, în cazul detectării unor erori este dificilă localizarea erorii. În acest caz se recomandă 
o testare succesivă a integrării modulelor, fie prin'metoda top-down, fie prin metoda bottom- 
up. În cazul detectării unor erori la adăugarea unui nou modul M eroarea provine fie din 
interiorul modulului M, fie din interfaţa modulului M cu restul modulelor. 

Testarea de, integrare trebuie să verifice si dacă funcționarea programului este 
conformă ou ceea ce scrie în manualul de utilizare a produsului. Scopul acestei testări este 
prevenirea descoperirii oricărot erori în testul de acceptare. 


Testarea modulelor nu poate fi făcută doar în faza de integrare. Este posibil ca íntr- 
un program complex un modul să fie folosit numai cu date de intrare care au o anumită 
proprietate, caz in care rezultatele sunt corecte. Însă Același modul poate da rezultate greşite 
pentru alte date, deci el nu este testat pentru orice date de intrare şi nu va putea fi refolosit 
într-un alt program ca modul testat. De exemplu, subprogramul 


CMMDC(a1,n2,d), 


care calculează cel mai mare divizor comun d al numerelor n1 si n2, testat într-un program 
în care parametrul actual corespunzător lui n2 e pozitiv dă rezultat corect, dar pentru n2 
negativ poate să nu mai fie corect. 


Orice produs program este testat şi de către beneficiar în momentul receptionárii 
produsului. Numim această activitate testarea de acceptare sau certificarea respectivului 
produs. Deobicei testarea de acceptare se face cu date reale. La această testare contează nu 
numai corectitudinea rezultatelor ci şi forma sub care sunt prezentate aceste rezultate cât şi 
utilitatea lor. O categorie specială de produse program, $i anume componentele sistemelor 
de operare, beneficiază de o atenţie deosebită în ceea ce priveşte această fază a testării. Sunt 
elaborate exemple de test, corespunzătoare fiecărei clase de asemenea produse comerciale, 
care se execută în scopul stabilirii performanţelor acestora şi de a le putea compara cu alte 
produse similare existente. In acest sens menţionăm cazul compilatoarelor pentru limbajul 
Ada, a căror corectitudine este certificată de un comitet de avizare al Departamentului 
Apărării din S.U.A. Fe i c 

; N Y 
Pe timpul întreţinerii programului unele părți din program sunt rescrise. Ca orice 
program nou şi aceste părţi trebuiesc testate. Astfel, vor fi testate toate modulele noi şi toate 
modulele afectate de schimbări. Evident, testarea de integrare este obligatorie. În cazul în 
care schimbările făcute n-au fost minore este necesară reluarea testării cu toate datele de test 
iniţiale. De aceea este necesară păstrarea acestor date de test în materialele care constituie 
" documentaţia programului. LA ' i 

Aparent testarea nu are legătură directă cu proiectarea. Indirect, este Se ca S 
proiectare perfectă va duce la o testare simplă, în care nu se vor descoperi erori, re tatele 
fiind corecte şi în forma dorită de beneficiar. Cunoaşterea activităţii: de See Ca S 

proiectant are însă influenţă şi asupra proiectării. Apoi, datele de test vor fi sta ied M i 
această etapă, iar testarea poate începe în paralel cu proiectarea, pentru mo e deja 
realizate şi pentru schema generală de programare. $ 


Aproapetoate sistemele de operare posedă instrumente de depanare a progr amelor. 


^ SOC er 


d 


So ud a mediile de programare moderne oferă pachete de programe care 
i atorul in depanarea programelor, prin execuţia lor pas cu i vizuali 
valorilor curente ale variabilelor. 5 j PLU 


x 1.8. VERIFICAREA PROGRAMELOR 


A program and its proof should be developed hand-in-hand, 
with the proof usually leading the way: SS ; 
: j Gries [Gri85] 


; Verificarea unui program este activitatea prin care se analizează dacă acesta satisface 

cerinţele pentru care a fost conceput. Ea este o activitate continuă, întinsă pe tot ciclul de viață 

. al programului şi conţine atât testarea cât şi demonstrarea corectitudinii programului, dar 

presupune mai mult decât aceste două activităţi. Ea se referă la verificarea fiecărei faze în 

parte din ciclul de viaţă al programului atât din punct de vedere al corectitudinii cât si al 
funcționării efective a acestuia. SCH EAT 


$ În primul rând trebuiesc verificate cerințele beneficiarului. Această verificare se face 

de obicei prin construirea unui prototip care este oferit beneficiarului pentru a-l examina. Un 

-prototip realizează o mică parte din viitorul produs, realizând în primul rînd operaţiile de 

intrare/ieşire. Astfelse stabilesc rapid informaţiile ce se furnizează programului şi rezultatele 
„care se vor obţine, precum şi forma sub.care ele apar pe ecran sau la imprimantă. 


dx eC. În cazul produselor complexe este nevoie de o echipă de verificare şi din ea nu mai ` 
trebuie să facă parte beneficiarul. Evident, va fi reprezentată echipa de proiectare, echipa de 
"implementare şi un expert în verificare. Se vor căuta erori care vor fi semnalate în scris. Dacă 
au fost descoperite erori, echipa de proiectare va revedea proiectul eliminând neajunsurile 
semnalate. Urmează reluarea verificării până când nu mai sunt descoperite erori. - 3: 
Íntrucát s-a observat cá multe erori se datorează unor greşeli făcute în specificare, - 


"este necesară în primul rând verificarea specificaţiilor. Acestea trebuiesc analizate atent, — 7 


căutate contradicții sau ambiguităţi încă înainte de a începe proiectarea. Specificaţiile 
trebuiesc analizate atent de către mai níülte persoane. E bine ca această verificare să se facă 
` de o echipă de experti în programare, lucru obligatoriu pentru produsele complexe. Este însă 
obligatoriu ca analiza să fie făcută nu numai de cei care au scris specificaţiile, ci de o echipă 
“mixtă. Din éa vor face parte cel puţin patru persoane: . SE - 
2 2 una din echipa care a scris specificaţiile; ES 
< ^.- una din echipa care va realiza proiectarea programului; ` 
--unadinparteabeneficiarului ee 


.- un expert care să onducă această echipă. XU ie 


SA 


“Toate concluziile vor. fi redactate: pentru a evita discuţiile inutile cu beneficiarul în faza de 
acceptare a produsului. < ` TP HA E aa EE Arc oe 
dere AGAM Ecl are scopul de a descoperi erori în specificaţii şi nu de a le corecta. 

- “Erorile vor fi menţionate în scris şi Vor fi corectate de cei care au avut sârcina să scrie . 

"specificaţiile, după care ele sunt verificate din nou. Verificarea specificaţiilor este considerată . 

terminată numai dacă nu au mai fost descoperite erori, - © oox 


„Verificarea trebuie făcută şi asupra posibilităţilor de implementare. Are 

“suficient spaţiu de memorie pentru produsul final, este. fiecare SC dară 
” corespunzătoare cerinţelor produsului? Este EE a condiţiilor de 
5 are a produsului şi din acest punctde vedere. —.. .— . ^ — EE 
EEN oea se realizează prin mai, multe forme, Astfel, ea începe cu 
verificarea proiectului fiecărui modul şi a interfeţei dintre module. Se poate demonstra 


WRA 
NS 


` D D 


E 


` ` activitatea cea mai dificilă dintre toate celelalte faze. ` 


corectitudinea unui modul sau testa funcţionarea acestuia. La nivelul între 
trebuie examinată atent interfaţa dintre module. Se va veri 
corespondenţa dintre parametrii actuali și cei formali. 

n această etapă se va verifica nu numai corectitudinea re 
ci și dacă ele corespund cerințelor beneficiarului, altfel ele sunt in 
De aceea se va verifica atent dacă fiecare cerinţă a beneficiarului, 
proiectare. 


gului program 
fica atent dacă este corectă 


zultatelor ce se vor obţine 
utile oricât ar fi de corecte, 
a fost inclusă în deciziile din 


COS In [Sch90] se subliniază că erorile trebuie descoperite cât mai devreme, pe cât posibil 
în faza în care au fost comise. Cu cât detectarealor întârzie cu atât costul realizării produsului, 
preţul plătit înlăturării acestor erori creşte. De asemenea, se menţionează exemple în care 
peste două treimi din totalul erorilor descoperite au fost aflate prin verificare, înainte de 
testarea:clasicá a programului. leat RA 2 , 


'19. INTRETINEREA PROGRAMELOR Bet 
Întreţinerea programelor constă din toate schimbările făcute după ce beneficiarul a 
acceptat produsul comandat. Motivele acestor schimbări pot fi multiple. 
*- În primul rând ne aștepăm la corectarea erorilor descoperite după acceptare, care 
constituie întreţinerea corectivă. NLIS i ' 


Există însă şi o întreținere perfectivă care constă din schimbările făcute cu scopul de 

a îmbunătăţi programul, a-i mări eficienţa şi, cel mai des, a-i adăuga funcţii noi dorite de 

beneficiar și utile acestuia. ENDE Den j SE 

; În sfârșit, putem, vorbi şi de o întreținere adaptivă, care constă din schimbări 
necesare adáptárii programului la mediul aflat într-o continuă schimbare. Ca exemplu, dacă > 

printre informaţiile cu care opera programul se. aflau și numerele de telefon ale unor 


„persoane, în urma schimbării sistemului de numerotare din 1992 sunt necesare schimbări în 


program prin care toate niimerele de telefon din Municipiul Cluj-Napoca se extind la şase 
cifre, primind cifra 1 în faţa numărului vechi. 2< epum atl AER Ren 


` Ponderea. acestor activităţi ín -totalul- activităţii de întreţinere” (dupá [Sch90]) , 
reprezintă: "xs EE 
- întreţinerea corectivă 17%; . . 

- întreţinerea perfectivă 60%; -` ` 

- întreținerea adaptivà 18%; —— — == o 0. 
„= alte activitățide întreținere 5%... 7 


p 


al programului (după Meyer [Mey88] chiar 70%). În același timp întreţinerea este considerată 


A * 


Se apreciază că în ciclul de viaţă al unui program. întreţinerea costă peste 50% din costul total - 


x E 


„Orice schimbare poate produce erori, Ca orice program nou si programul obținut în 
urma întreţinerii trebuie testat. Această testare trebuie să verifice dacă modulele schimbate 


funcționează corect şi dacă schimbările făcute nu au efect negativ asupra celorlalte părți ale 


“programului, — -` 


„Evident că pentru a reuşi să facem schimbări într-un program sunt necesare cât mai 


- multe informaţii despre acest program. Deci este foarte utilă documentația programului pe 


toate modificările făcute şi Cauzele acestor modificări. > x ns 
UT EHE Be: timpul întreținerii. unui pen ae obțin mai multe versiuni succesive. Se 
recomandă păstrarea tuturor versiunilor... * 


toată durata înțreţinerii. În acelaşi timp întreţinerea trebuie să actualizeze documentaţia cu. 


N 
N 


$ j | De E , t D i A 
E Via ` t d ` 
d boy D 
^ 


1.10. DOCUMENTAREA PROGRAMELOR 


Această activitate are ca scop prezentarea produsului program 
fi interesaţi să obţină informaţii despre acest GE Cate ee Bor de 
rând realizatorii programului, utilizatorii şi persoanele solicitate să facă întreţinerea ip 
` Documentarea completă a unui program se va referi la toate fazele din viața acestui 
"deci va conţine următoarele categorii de documente: e 
- cerinţe; 
- specificaţii; 
- documentaţia de proiectare; 
` - documentația de programare; : : 
- datele de test; i 
- documentaţie privind exploatarea programului; | 
- schimbări pe timpul întreţinerii programului. ` i , 


„Există două mari categorii de beneficiari ai documentaţiilor: utilizatorii programului 
ŞI specialiştii implicaţi în elaborarea şi întreținerea acestuia. Este evident că personalul de 
exploatare nu trebuie să cunoască decât cum se folosește corect programul în cauză, deci 
pentru el este suficientă documentaţia de exploatare şi asistenţa on-line pe care o poate oferi 
“programul. Cele mai recente produse. realizate de firmele consacrate au, pe lângă 
documentaţia scrisă şi o autadocumentaţie dată prin funcţii HELP... 


v 


B 


Consideraţiile care urmează se referă la procesul de realizare şi perfecționare a 
- programului. Adeseori se întâlnesc programe fără nici o altă documentaţie în afara textului 
propriu-zis al programului. În graba de a termina cât mai repede, programul mu este însoţit 


de nici o documentaţie si frecvent nu sunt folosite nici comentarii în textul programului. Cei 
care au dorit să refolosească programe scrise cu câteva luni în urmă înţeleg foarte bine 
diferența dintre un program însoţit de comentarii explicative şi un program fără nici o` 
explicaţie. Uitarea acţionează asupra oricărei persoane şi, chiar dacă este posibilă, descifrarea 
unui program cere timp şi nu este o sarcină prea uşoară. Comentariile sunt recomandate, fiind. - 
- un mijloc de autodocumentare a programului sursă. ^ ` Ro 

Sigur că prima documentaţie a oricărui progiam este textul sursă propriu-zis. Este ` 
bine ca acest text să poată fi citit cát mai uşor, iar programarea structurată duce la un program 
mai uşor de citit decât unul lipsit de orice structură. Dar sunt hecesare şi comentariile, a căror 
folosire este oferită în fiecare limbaj evoluat de programare. - i. : 

„+ Este însănevoie şi de o documentaţie însoţitoare scrisă, care constituie documentarea 
propriu-zisă a programului. Aceasta trebuie să redea toate deciziile făcute în timpul 
proiectării, să prezinte diagrama de structură a întregului produs ŞI fiecare parte separat. 
Pentru fiecare modul documentaţia va conţine: - EA ; 
= - numele acestuia; - . e SE 

- - datele de intrare; EC A SE 
EE 
- funcţia realizată de modulul respectiv, — 

_ variabilele folosite şi semnificaţia lor; 
- algoritmul propriu-zis. . | SE dee : 
— Este bine Me TE se afle sub TTE om si in textul programului. 
menea, documentaţia va conţine textul final al programunn- TE 
pru pac necesară şi 2 documentarie de folosire a produsului realizat. ee nu este 

` interesat de modul în care a fost realizat programul ci de modul în care îl poate lo e SC 

O documentare completă a unui program poale fi utilá nu numai pentru folosir si 
întreținerea programului; Componente ale unui produs existent De WE 
altor produse, Este însă necesar să se înțeleagă cât mai uşor ce ctii realizeaz e 

) i perf “Folosirea acestor componente existente, testate şi 
componente şi cu ce per orman[e. “Folosirea. acest n uiro 

` documentate, duce evident la creşterea productivităţii in realizarea no x pr SCH d 
2 Íncheiem spunând că orice informaţie suplimentară furnizată despre p 


e 


a. 


n 


E ' M 


M 


program poate fi utilă. 


1.11. PROIECTAREA ASCENDENTĂ ŞI DESCENDENTĂ 


: Există două metode generale de proiectare a algoritmilor, a căror denumire provine 
din modul de abordare a rezolvării problemelor; metoda descendentă şi metoda ascendentă 


Programarea descendentă (top-down) porneşte de la problema de rezolvat. pe care 

o descompune ín subprobleme independente, care la rândul lor pot fi E în 

subprobleme. În final, se;va descrie subalgoritmul de rezolvare al fiecărei subprableme, dar 

şi interacţiunile dintre aceşti subalgoritmi si ordiriea în care ei sunt folosiţi. 

: Ca exemplu de proiectare descendentă vom descrie un algoritm specific lucrului cu 
fişiere, corespunzător următorului enunţ: 


„Se cere să se conceapă un program care să creeze, actualizeze şi exploateze 
un fişier cu studenţii facultăţii de matematică şi informatică. 


Chiar în enunţul problemei se menţionează trei activităţi. distincte, care vor. fi 
realizate prin subprograme distincte: CREARE, ACTUALIZARE şi EXPLOATARE. În 
arborele de programare aceste module sunt notate prin CRE, ACT, respectiv EXP. 


* În crearea unui fişier -cu studenții unei facultăți se va repeta Scrierea în fişier a 
informaţiilor referitoare la câte un student, până când nu mai sunt studenti de introdus, sau 
se termină ziua de lucru, urmând să se continue în ziua următoare. Apare aici necesitatea 


` introducerii în memoria calculatorului a informaţiilor despre un student, pentru care vom 


concepe un subalgoritm CITESTE (notat CIT). Acest subalgoritm va fi apelat de 
subalgoritmul CREARE ori de câte op este necesar. d 


Subalgoritmul ACTUALIZARE poate realiza mai multe funcţii. Ca. exemplu 
menţionăm. funcţiile: adáugare de noi înregistrări: în fişier, ştergerea unor înregistrări din 
fişier, actualizarea unor informaţii în înregistrările existente în fişier, cum ar fi trecerea notelor 
obţinute în- ultima, sesiune de examene, etc. Acestor funcţii le va corespunde câte un 
subalgoritm; în cazul nostru ADAUG, STERG şi COMPLETEZ (modulele ADA, STE, 


respectiv COM în arborele de programare)? d 


În sfârşit, subalgoritmul EXPLOATARE poate realiza mai multe funcții, apelând 
câte un subalgoritm corespunzător. Astfel, menţionăm trei subalgoritmi şi funcțiile lor: 
- LIST, pentru listarea tuturor informațiilor din fişier; 


-. CĂMIN, pentru listarea tuturor studenţilor care locuiesc în căminele studenţeşti; 
- RESTANT, pentru listarea tuturor studenţilor căzuți la cel puțin un examen. ` 


„Aceşti trei subalgoritmi. vor tipări de mai multe ori informaţii referitoare la un ` 
“student. Deci toţi trei apelează un subalgoritm TIPAR pentru listarea informaţiilor unui 
student (modulul TIP). Se ajunge la diagrama de structură dată în figura 1.11.1. 


` Pentru descrierea subalgoritmilor corespunzători este necesar să cunoaştem exact 
care este structura unei înregistrări pentru un student si care sunt variabilele auxiliare de care 
avem nevoie. Pentru a păstra schema de mai sus si a folosi subalgoritmi cât mu in Sv 
considera că fişierul cu care lucrăm este secvențial şi algoritmii vor fi programaţi în limbaju 
Pascal: . 4 Ko , 


informaţiile referitoare la un student. Vom considera 
anul de studiu, grupa, numele şi prenumele, notele, 
ă, în gazdă sau la cămin? : 


„Astfel, vom nota prin X toate 1 
că acestea sunt; numărul matricol, secţia, 
dacă este sau nu bursier, unde locuieşte: acas 


V 


D 


: Variabila Ger c va lua una din valorile œ TAN 

„ dorită, aleasă dintre următoarele trei posibile: creare, 

folosită şi în subprograme într-un scop similar, V 
marchează un fişier de lucru (temporar). , 


;sau E), în funcţie de operaţia 
actualizare sau exploatare, Ea poate fi ` 
ariabila f notează fişierul creat, jar. g 


a - ` 4 D ^ $ 
Figura 1 11.1. Diagramà de SEH a programului put luc cu er 
E continuare vom descri negen amintiți mai sus, GAR f S 
„/SUBALGORITMUL Citire(X); ` EE 
S H er Sewer de la consolă norma naționale mai sus s n depune in x 4 
ny „SF-Citire | SC Ki EE SE x 
 SUBALGORITMUL Tipar; er e UI dau) SS 
—. f]Iadin memorie informaţiile eani le en într-o Tu dori de. PET 
D ME ET beneficiar. EE - Se Ee 
i k SF-Tipar EE GE EE - 
a | SUBALGORITMUL Creure(f) EE E 
SE Sr EE SEH d EE EE 
EE ; VATES 
VAR E orgoliu |. CHEAMĂ Citire(X); 
EE Dach nrmatr «0 ATUNCI. CHEAMĂ Se, a 
EE : [scrie pe X în f} ES A fp e E RM d 
SEH - PÂNĂCÂND ünmatr-ÜSEREP i | 
TAA (Se consideră că numărul matricol este. pozitiv i devine 0. pus nu mai sunt 


Ia VIE Së SE ix înregistrări } ` i a PA DR DU LUC 
EUR rosea. UR E LE UY URN. i 


PEU cd ` SUBALGORI: MUL Actualizare); RIS 
e 1 Realizează operaţii asupra fişierului f 
+ adáugári de noi: inregistráriinf, = 
SE “ştergerea, unor înregistrări dief ` SE : tă 
^ .- corectarea unor informaţii, peres ARE NN WIES 
EE prin dialog cu beneficiarul |. D mia, ; 
D E DAN DEI EU 
A SERA d ` Citește c PA’, CH mm: Bee SE A te 
Ee M SERI ORE AZA E DINTRE S AM LE RS YT ia aril i 
ce eL SE 2 d "A; CHEAMĂ Adaug(f; ee, KT 
LEE e de CHEAMĂ Corectez(D; ` Pur OON EIUS 
11 4214. E CHEAMA SIBI UR ta ed. A e 
EE e terminare. subalgoritm]. PASEAR ED E [E 
; ; e 5 dă SFSE L. end? E ai 9A A WS ) NE : / x d . N Lt 


- PÂNĂCÂND c ="T'SFREP 
SF-Actualizare 


SUBALGORITMUL Adaug(f); e 
* Poziţionează cursorul la sfârşitul fişierului f. 
REPETĂ : 
CHEAMĂ Ciüre(X); 
ES ES DACĂ nrmatr«0 ATUNCI ` 
> : CHEAMĂ Scrie(f X) ( scrie pe X inf ) 
d PÂNĂCÂND nrmatr -0SFREP ` e 
SF- guum A 


SUBALGORITMUL Corectez(D; 
{ feste fişierul, existent, iar g un fişier temporari es 
REPETĂ - 
` CHEAMĂ Citeşte(f, X) = nregitărea curentă din na 
“CHEAMĂ Tipar(X); 
- Dacă (*doriţi. corectarea lui X.) p QUIM ur 
„ATUNCI *corecteazà peX. o Ee 
SFDACÀ .  . us eue x R eis | 
CHEAMĂ Scrie(g,X) : ADU SER eode 
PÂNĂCÂNB *sf- Sur SFREP SIE Etna cca AU ae, a UE TOT ERE 
d S See NUM i 
> SF-Corectez. . 
'SUBALGORITMUL saat: 
REPETĂ , 
< CHEAMĂ Citeste(f, X). es 
"CHEAMĂ Tipar(X); SE i Eee TR o EE 
„DACĂ (*nu doriţi ştergerea fui ai EE 
„ATUNCI CHEAMĂ Sene(uX) 5 ie 
SES CSHDACAT S SE 
PÂNĂCÂND *st-fisieřului f. SEREP .. i. i EAE 
: stan SE 


SE SUBALGORITMUL Enos, SEA 
EE - { Realizează listarea: ^ 

AAR Sa “- înregistrărilor fişierului f; - 
„= studenţilor cáministi diat 
„= studenților E af + 


5 CHEAMĂ Ca 
Ri CHEAMĂ Restant(I); 
qa ICTU. [terminare SEHEN ee S 
PAULI AE "PÀNACAND c= SE REF ESD ia e DA DURER 
poo oun, L Se Eăploatatei icis pros Ux ias EAE CASERO 
Ge E E SUBALGORIIMUL Léa Si QE NN EO 
* VERUS Ti a Co TU CHEAMĂ Cet. 3 tă £ LP 
REGINE -CHEAMA Tipar): MEN 


PÂNĂCÂND *sf-fisierului f. SFREP 
SF-Listare 


SUBALGORITMUL Camih(f); 
REPETĂ 
CHEAMĂ Citegte(f, X) 
DACĂ (*X stă in cămin.) 
ATUNCI CHEAMĂ Tipár(X); + 
_SFDACĂ 
: PÂNĂCÂND "sf-fişierului f. SEARE : GER 
SF-Camin GE > 


SUBALGORITMULRestant(f); ^. * 
REPETA 
CHEAMĂ Citeşte(f,X), — ' 
DACĂ (*X are note sub 5.) ATUNCI CHEAMÁ Tipar O; 
PAÁNÁCAND em f. SE 
E EE SE 2 


În multe cărți metoda top- EE este, numită şi stepwise-refinement, adică rafinare 


- . succesivá. Este vorba de un proces de detaliere păs cu pasa specificaţiei, denumit proiectare 
"descendentă. Algoritmul. apare în diferite versiuni succesive, fiecare fiind o. detaliere a 


HH 


versiunii precedente.. În aceste ver siuni succesive „apar “multe enunţuri nestandar dce urmeazá 2 


ab precizate treptat prin propoziţii s Standard. Se recomandă ca ele să rămână comentarii în - 
-` versiunea finală. Algoritmul apare în versiuni succesive, tot mai complet de la o Versiune. la, 
À alta. În v ume finală î in algoritm apar numai proponis standard. D 


-Ca ampla de. rafinare succesivă ne propunem s să SE un n algoritm care să, 


rezolve următoarea problemă: Euros Lo 


y 
X 


Sé dau EE întregi KE 3 X. 
sf Se cere să se reţină într-un vector X numerele, distincte. 


e este CHE în versiuni “succesive, focare, fiind O rafinare a versiunii 


uc. e În toate aceste versiuni i specificarea problemei ec constă din: 


DATE n; il D i 
-REZULTATE Ek =1 235 (numerele « distincte dintre numerele date) 


: “variabilele, intermediare SEI si semnificaţia lor, precum ŞI metoda folosită vor ` 
E EE rafinărilor succesive n reies ci textul cp 


„ Versiunea BG 


Se Zeie SS =x EE 
07. PENTRU i EXECUTĂ one ed Ra Se 5 
EE d * Verificá. dacăxeY= iysys- SY | EA 
277.4. * Dacánu. SE atunci SE pex milii Y. PEN E 
S SEPENTRU EE EE 


V 


: | Decizia c ce uebie lusti este. cum:să verificăm da udu element a la Q^ 
„mulţime « dată Y orala din k Elemiente. Pentru aceasta definim funcţia: 


dec 4 ` t » 


FUNCŢIA APARTINE(a,k,Y) ESTE: 
r: = fals; : z 
i=l; 
CATTIMP (not r) şi isk EXECUTĂ 
DACA a=y, ATUNCI r: = adevărat 
ALTFEL i; =i+1 


. SFDACA 
SFCAT' 
APARȚINE: =r 


SF-APARTINE 
Versiunea finală constă din funcţia definită mai sus si urmátorul algoritm principal: 


ATRIBUIE k:=1; y;-xj .— 
PENTRU i:=2n EXECUTĂ | d e, 
DACĂ nu APARTINE(x,k,Y) ATUNCI k: =k + 1;y;: =x SFDACĂ 
SEPENTRU. .. | ; SE 


» 


. ^. Se observă cá în fiecare Versiune algoritmul este car st corect, dar este incomplet 
descris în yersiunea întâia. În versiunea finală algoritmul este complet descris şi sunt folosite 
numai propoziţii standard, E nOD qq duo Ee 

- Diferenţa între metoda top-down şi metoda rafinării “succesive este neesenţială, 
` scopul urmárit fiind acelaşi: concentrarea atenţiei asupra părţilor importante ale momentului” 
şi amânarea detaliilor pentru mai târziu. Dacă ar fi necesar să le deosebim am spune cá 
metoda top-down se referă la nivelul macro iar metoda rafinării succesive la nivel micro. La 
` nivel macro se doreşte descompunerea unei probleme complexe in subprobleme. La nivel 

micro se doreşte obţinerea unui modul în versiune finală. Într-o versiune intermediară pot fi 
prezente numai părţile importante ale acestuia, urmând să se revină asupra detaliilor în 
versiunile următoare, după ce aspectele importante au fost rezolvate. - 

` În [Raj85] se extinde metoda rafinării succesive la programe complexe, deci metoda 

se foloseşte şi là nivel macro., — xu MMC QM MR E piat s 
Avantajele programării top-down sunt multiple. Avantajul principal constă în faptul 
„că eà permite programatorului să amâne detaliile pentru mai târziu. În momentul în care , 
` descompunem problema în subprobleme nu né gândim cüm se vor rezolva subproblemele ci 
care sunt ele şi conexiunile dintre ele: pe 
Chiar dacă iniţial problema nu este complet specificată pe timpul proiectării top. , 
down şi a rafinării succesive se poate reveni la specificarea completă a problemei şi apoila — - 
continuarea eg DEE EE EE 

Programarea descendentă permite lucrul. în. echipe. mart. Prin descompunerea 
"problemei ín mai multe subprobleme, fiecare subproblemă poate fi dată spre rezolvare unei 

subechipe. Fiecare subechipá nu cunoaste decát subproblema pe care trebuie să o rezolve. 


subalgoritmi existenţi, pe care îi asamblează în alţi subalgoritmi pentru a ajunge în final la 


itmul dont, ` cuvinte, în E dei ` fi scris nfai întâi 
algoritmul dorit. Cu alte cuvinte, în. cazul metodei "ascendente va f intà 

SE apelat şi apoi cel care apelează. Ca rezultat al proiectării ascendente se ajunge 
“la o mulțime de subalgoritmi care se apelează între ci. Este important să se cunoască care 
subalgoritm apelează pe care, lucru redat printr-o diagramá de structură, ca si în cazul , 

amării descendente. Uic MOESIA EN RORE Se 

program Această metodă are marele dezavantaj că erorile de integrare vor fi detectate uran, 
abia în faza de integrare. Se poate ajunge abia acum la concluzia că uncle subprograme, egi 


` corecte, nu sunt utile. ` 


- Metoda ascendentă (bottom-up) -porneşte de la propozițiile limbajului şi de la 


D 
D i + 


- 


E De cele mâi multe ori nu se practică o programare ascendentă sau descendentă pură 
cio combinare a lor, o programare mixtă. Ca exemplu de programare mixtă vom proiecta un 
program. care să genereze şiruri de numere aleatoare și să verifice concordanța lor cu 
reparü[ia „respectivă. Presupunem că cititorul cunoaște problema generării numerelor 
aleatoare şi testul hi-pătrat pentru verificarea concordanţei unor date de observaţie (sau: 
„generate artificial) cu o repartiție dată. Dar ceea ce urmează se poate înțelege şi fără a fi- 
familiar cu aceste cunoştinţe. SUUS NE CIAM T 


w Laun prim nivel de descompunere a problemei vom avea trei nodul rom ă 
3 l ; „aşa cum 
diagrama de structură din figura 1112. + : a ra 
: ^ NO j j E ` ne d í 


e aleatoare și este format dintr-un ` 
indicând repartiţia dorită. Modulul ^ 
VER constă d (rep): care are. drept scop de a verifica dacă  - 
. numerele generate concordá cu repartiţia menţionată prin rep. - EE - 


1 
Pentruagenera un șir de numere ^ ^ ^. 0 
: EAS ru Sp ES "s MM a : UNT 
Me "Xi pe ap d SE 
et e LO [ n? 


sistemele de operaré oferă funcţia random in acest scop. Pentru alte repartiţii se cunosc 


d S 


oiectári constă în faptul că modulele RAN, NOR, EXP 
ise în momentul proiectării, deci înaintea modulelor din. 


ess 


$4 7 


E E Ee, de f ATE IG Le 3 


SE SE EE Aa pa eS cata A ia de structură > ` 
| ^. Figural 113. Diagrama de.structură Beet A Diagrama ce Str Se 
SE SE lulu GEN în a programului NR ALEATOARE . 


d SI fe 1 


e * 2Q. PTAS 


Pta rim, 7 . TEY LA RA! ACA ab Y BIN 9 


Si 
aka 


x e 


1.12. PROGRAMAREA MODULARĂ 


Prin programare modulară ínfele i alin 
rezolvarea unei probleme prin poză pri îi SE EC Geh 
programarea separată asubalgoritmilor corespunzători. Astfel, Se is ia SE s 
numai asupra subproblemei pe care o are de rezolvat, considerând-o. ca brobje de bs 
státátoare. Evident, ea este mai simplă şi mai uşor de rezolvat decât probl intrez E ER 
şi aici folosim termenul DT: în sens L ru î BI poa DU ML Deci 

: : programare în sens larg, pentru întreaga activitate de realizare : 
programului (proiectare şi implementare). De altfel, considerăm că într-o program: a 
serioasă nu se poate ajunge la implementare fără a avea în prealabil algoritmii desit 
limbaj de descriere (la noi Pseudocod). Deci programarea modulará se referá ín primul ránd 
la proiectarea modulară a algoritmilor si apoi la traducerea lor în limbajul de programare ale 
ținând seama de specificul acestui limbaj. ke ; E E 
SS SE We EAE Ris este stráns legatá de programarea ascendentá gi 

amaréa descendentá, ambele pr à 1 itmi 

EE p esupunând folosirea subalgoritmilor pentru toate 
Am vorbit de programare modulară şi am folosit cuvântul modul fără a-l defini. De 
fapt ce este un modul? Modulul este considerat [Sch91] o unitate structurală de sine 
stătătoare, fie program, fie subprogram, De o unitate de program. Un modul poate conţine 
sau poate fi conţinut într-alt modul: Un modul poate fi format din mai multe submodule. 
‘Astfel, în limbajul Fortran, în urma compilării, din fiecare subprogram se obține un modul 
„obiect, asa cá putem considera fiecare subprogram un modul. La fel în Pseudocod fiecare 
subprogram şi programul principal sunt considerate module. În limbajele cu structură de bloc 
-. (de exemplu in Turbo Pascal) UNIT-urile pot fi considerate module. La compilarea separată 
un grup de subprograme compilate: deodată constituie un modul, dar acest modul poate fi 

considerat ca ó mulţime de submodule din care este compus. i SH , 


„Este însă important că fiecare modul să-şi aibă rolul său bine precizat, sá realizeze 
o funcţie in cadrul întregului program. El apare în mod natural în descompunerea top-down. 


X i B a EI . Co e LS < E 
in structura unui program, dacă funcţia pe care o realizează modulul M încă este necesarà,. 


acest modul trebuie să fie util si folosit in continuare fără modificări. . + 


“Avantajele programării modulare sunt multiple. Menţionăm. în cele ce urmează 
câteva dintre ele. Descompunerea unei probleme complexe în subprobleme este un mijloc 
convenabil şi eficient de a reduce complexitatea (Principiul Divide et impera acţionează şi în 
programare). Este evident că probabilitatea apariţiei erorilor, în conceperea unui program 
creşte cu mărimea programului, lucru confirmat şi de experienţa practică. De asemenea, 


rezolvând o problemă mai simplă, testarea unui modul se poate face mult mai uşor decât 
„testarea întregului algoritm... S : 


"compilarea separată a subprogramelor şi la păstrarea subprogramelor testate în biblioteci de 
subprograme, de unde ele se pot refolosi la nevoie. Sunt cunoscute astăzi multe astfel de 
` biblioteci de subprograme. Proprietatea de reutilizabilitate a acestor subprograme este foarte , 
2 importantă în activitatea de programit: Eà duce la mărirea productivităţii în programare, dar 
ai ea siguranţei în exploatare... `s ji RS n 
n. ia deser Steg algoritmului sau a implementării lui, se ajunge la 
concluzia că proiectarea a fost incompletă sau că unele module sunt ineng 2 În agati 
situaţie programarea modulară este avantajoasă, ea permiţând înlocuirea modulului în cauz 


- cu altul mai performant. 


:. .. Modulele se pot refolosi ori de câte ori avem nevoie de ele. Astfel, s-a ajuns la 


; i l : 
4 : s ; a 39: 


` subprograme (GENEREZ şi 


IMPLEMENTATION 


CAS var iinteger; EE 


„end {norm} | P K S ^ : ORE i: s Ă E INE s 


dd Una din activităţile importante in realizarea “unui program este verificarea 


udinii acestuia. Experienţa a arătat că modulele i ât mai 
udinii acestuia. se pot verifica cu atât mai uşor cu câ 
Sunt mai mici. Abilitatea omului de a în e 


' elege şi analiza corectitudinea unui subalgoritm este 
ta mai mare „pentru texte scurte. l unele cărți chiar se recomandă a. nu se folosi 
Subalgoritmi mai mari decât 50 de propoziții. Sigur cá o astfel de limită nu există, dar se 


recomandă descompunerea unui subalgoritm în alți subalgoritmi oricând acest lucru este 


posibil în mod natural, deci aceşti noi subalgoritmi rezolvă subprobleme de sine stătătoare 
sau realizează funcții bine definite. GE 


i . Concluzionánd, considerăm că programarea modulară are următoarele avantaje 

importante: i ; : : Ke y 
„= compilarea separată; 

- testarea separată; ex : 

- extensibilitatea ugoará a produsului format din module; 

- folosirea bibliotecilor,de subprograme. 


Este posibilă conceperea de module dedicate unui anumit scop, dar realizate independent de 


.. problema concretă de rezolvat. Ele sunt folosite în activitatea de programare asemenea 


cărămizilor într-o construcție. În acelaşi timp ele sunt concepute, din proiectare, cât mai 
general posibil, în vederea unei largi utilizări a lor în cele mai diverse probleme. 


Ca. exemplu de programare modulará vom -da programul Pascal corespunzător 
problemei: definite în secţiunea 1.11, pentru care s-a proiectat programul cu diagrama de 
structură din figurăl.11.4. În acest program se definesc două unit-uri, pentru cele două 

VERIFICA) 


apelate din programulprincipal. ——————- 


T 


type vector.— array[1..nn] of real; Eo or s c A SS 
vecf = array[1..10] of integer; 


repart = (Uniforme, Normale, NormaleO,Lognormale;Exponent); s : : 
procedure GENEREZ( EE:repart; n:integer; Var x: vector )r do NU T : 
EN . —  ('Genereazá n numere aleatoare depuse în vectorul x, corespunzătoare 
S repartiţiei EE} — ` 2 STONE 


x 
. 


procedureGenerez; 70000. uu aa (modulul GEN ]- 
Sa C:ChAr e Se EE 


i Cal bu 
"y 1 


ediny red; 000 p SE 
umăr aleator corespunzător repartiției N(0,1) } 


E 


A 


dE SS EE : Aal E SS EE ` - ~ x NW . 
Sek ito 12 do z-z*random  . ^ S f nodului S b : 


Paco a HEAR fe o LOG) 
function lognorm : real; KEE 4 SE N pM 
ICH, "7 "`t Genereazii un număr aleator (corespunzător repartpor VENSE 


EE valoare medie și abaterea standard date în procedura Generez] MU 
var zireal;, Qu AMA Y OP SEO 
begin, nnn WC A i d 
zZ > norm;. í de SE s 


* D 


z: = z* abaterea + media; 
lognorm: = exp(z); i 
end; 


so 


H 


function exponen ; real; { modulul EXP) 
e ( Genereazá un număr aleator AU r 
epartiţiei exponenţi 
parametru lambda ) ka i " y d 
var z:real; 


begin 
Z: = random; 
exponen: = Vos) ambi i i "n : 
end; S 
begin tGeherez) A SE : sc Ge 
= Case EB of 2 X 210 [ 
Uniforme: for i: =1to n do xli]: S tandon; EE LAS 


Normale: for i: =1to n do x[i]: = = norm; 

NormaleO: begin XA S 
writeln? media = ?); See ; 
.writeln(^ dispersia = SE EIUS 
if abaterea > 0 then. dus 


à begin abaterea: =sqr(abaterea); : Ne S 
SS ` fori:=1tondo. EE 
x[i]: = mediă + abaterea“norm ` pe SE IRE 
i endelsé ` EE i ga em 
' begin CS es n: QR SU T RSA A eta IUE 
E „write gere nu ese negativa’; E eee cce A 
S EE end; : dc a M UM Um 
n end; ` MESE Em e : ` tI ; Tir : 2k SC j^ ; D 
Exponent: begin ; : NE ERORE S 
VE EE 2 E AN US 
x so Ca ford org suponen. SE um m UMEN e 
: cc endi sed e D S 
 Loenormale begin wriţeDati E ES mz- J: tech EA EK 
o 7 writeDati dispersia dz2 =°); COUR. 2s 
susce »vbaterea; —log(1 + dz2/mz/mz); ` : 
EIER = log(mz)- -abaterea/2; ` 
: Xp que ke e abaterea: = sqru(abaterea); Se 
E end; P SE, LAN 
- end; i Generez ) ` : S 
INTERFACE. EE ea a. Sa E) Aa NU NEQU E 
x uses gen; E a. uu DR M Qu d "m ODDS : 
; var x vector SE EE A OS ES 
| procedure verificat inte umerelor tea z SE : 


E E verificá reparti(ia num S ` e 
j ori SE Hepat GER VER)... Ru m I S 


IMPLEMENTATION Ua E 


procedure Verifica; DINE 

„Var e : array[0:20] of real; TN e 
fft: vecf; ES 
nj : integer; i 
hi2: real; 


( modulul VER ) 


[] 
procedure citestef(m:integer; var t: veci); 
. ( Citeste fr ecventelé teoretice qi) i i-1,m k 
; var itinteger; j 
begin ; ; 
for i: =ttomdo o; A ADR 
` begin : ; dx P E : 
; 'wnte(tQi)-?) ——- Heu ace od, p n pla LER d 
: | readla(li] TON REAL HE E E OLSAN i făt a La d ELO I AT. 
S endi. NIRE M TT HUS IUE d SE d 


` 
x 


procedure grupez(n; integer; „Var wd oet 


fori: ären de EE v T HOS p TEC EE 
T lS ama then Vues Zur EE SC 
SE 
Ze 9 : SR 
21 A e S St SEATS Ce à 
- for Vois ad oo sardi AU, FERME ERAN 


«0 syriteC Se Ge 2 "PRA A SR 
» cen Ee i i ss AA ; P eS n i S AN Oe 


Ud. SUR Pa 


& 


: SE ani i de SE 


a EES Generez(NormaleO, xh 


end. (Unit VER } 


program NrAleatoare; S 


“4 Generează numere aleatoare având una din reparti(iile; 


Uniformá, Normală, Lo ală 
uses genver; | gnormalá, sau u Exponenfialà ) i4 


var n: integer; : ! 
X: vector; : S ; ER 
c- ` char; Et ^ 
begin S d > (VR ; h 
repeat SEn EE : A 
` write dati nr probelor:in =>); ^ ' ^ : : 

. readin (n); die ges x 
(0n) and (n<: — -nn). | Di EDU IT 
then.C; -'S' gos Wer Ga, [5 
else wtitelnN SE < nn) ez SCADA aia EE 

“until (0<n) e tei n) eis Io E Td SE 
randomize; : x e SAS ud Qu 
writeln;. writeln; ` UOI I UNT D m EE SE 
Repeat GE p (pc a ACRA NEM 
‘writeln; writeln; ^.^ 05. NIU DM NT pă i 
writeln('Unifarme: A [Aia ea Oud UU o 
BEE Nees NEE 
writelnnOrmale N(as)); E 05 70 VO DUM TEE 
writeln("Lognormale:"); MIC QNNM 
SE B B EE 
. writeln(Stop); |... SE SE SE 
writeln; writeln; ' E EE 
z write A lect pi prin litera mare, fuscis dorit ) 
write? Functia = ?); readlni(C); SE 
~ Case C of UU 
SGH BIA Geneseos aia A 
CN Generez(Normale,n,x);. 


22) 2: Generez(Lognormale, DX) : 
SEDE Generez(Exponent.ax EE 


1 


; de "programare SEH în urma à cxperienfei 
“Ea cere resp ctare. unei discipline. de'programare si folosirea ` 
i va ei R un Ee: de urmărit, ` 


GZ 


` riguroasă. câtorva struc turi ide caleul. Ca: 
- darsi I USATE 


Im , crat in literatura. de 
Med fe ermenul TO, ue folosit î în titlul acestei. secțiuni şi consa : 
S EE éste. degen în sens | larg şinu este identic cu cel de sana act e, 
d vorba de ín întreaga activitate depusă pentru obținerea unui program, ect atăt proi 


ro riu-zisá.. NEMO M 
EE GH e Bees că orice algoritm poate fi compusi dinnumai ` 


"v Va N 


A ese atrage, celui i ua Ale ata AS NE tea MA dea DO Ge 


^ 


x 


- structura secven[ialá; 
- structura alternativă; 
3 - structura repetitivă. 
Fiecare din aceste structuri, ca parte dintr- 
Jesire şi sunt prezentate în figura 1.4.1. 


o schemă logică, are o singură intrare si O singură 


caracterizată ca fiind: 
- "programarea fără GOTO"; ` 
- "top-down programming"; 


- "o manieră de a organiza si codifica programe astfel încât să fie uşor de înţeles şi 
modificat"; A 


- iar scopul este "... de a controla complexitatea prin teorie și disciplină”. 


De fapt ce este programarea structurată? În [Te076] programarea structurată este 
d y. ; 


Lë 


În [Knu74] Knuth consideră programarea structurată ca fiind un mijloc de a face 
produsele program mai ușor de citit. Schach [Sch90] consideră programarea'structurată. ca 
fiind programarea în care instrucţiunea GOTO este folosită la minimum şi numai în jos. În 
[Ric80] programarea structurată este definită ca fiind programarea în care abordareaeste top- ` 
down, organizarea muncii este făcută pe principiul echipei programatorului şef, iar în 
proiectarea algoritmilor se folosesc cele trei structuri de calcul definite de Bohm-Jacopini. 

i Alţi autori consideră programarea structurată nu ca o simplă metodă de programare 
o ansamblul tuturor metodelor de programare: cunoscute. Dar programarea modulară, 
programarea top-down, sau bottom-up au apărut înaintea programării structurate. Important. . 

- este faptul că programarea structurată presupune o disciplină în activitatea de programare. 
„Considerăm că programarea structurată se poate flot: 
>= la nivel micro, privind elaborarea unui subalgoritm; i 
„= lanivel macro, privind dezvoltarea întregului produs. 


- . Lanivelmiero programarea structurată este cea în care autorul este atent la structura 
fiecărui modul în parte, cerând claritate şi ordine în scriere si respectarea structurilor de calcul 
definite mai sus. - : Soupe sce ree terr Es 


La nivel macro programarea structurată presupune practicarea proiectăriitop-down, 

a programării modulare şi a, celorlalte nietode de programare, cerând ordine în întreaga 

activitate si existenţa. unei structuri clare a întregii aplicaţii, precizată prin diagrama;de 
structură a aplicaţiei. ` : 3 SURE MU EE WORDEN 

În acest scop am definit limbajul: Pseüdocod, care are structurile de calcul 

` menționate, dar nu are instrucțiunea "GOTO". Schemele logice obţinute dintr-o descriere în 

Pseudocoda unui algoritm, conform semanticii propozitiilor Pseudocod, se numesc D-scheme 


(de la Dijkstra) sau scheme logice structura te. : 


TAR Privind claritatėa algoritmului trebuie să observăm căidentarea (paragrafarea) este 
un alt mijloc de a mări claritatea scrierii: Textul unui algoritm poate fi scris cuvânt după : 


cuvânt, completând rot rândul asemeni textului unui roman. Astfel, următorul text este identic 
ču algoritmul CLASAMENT prezentat în secţiunea 1.4.2, dar claritatea lui este incomparabil 
E nas mica : S A SC ES S UE x x wes x : KE CC 
PROGRAMULCLASAMENT ESTE: DATE m,n,NUME, i 1,n,NOTE, pjah KR 
: i215 PENTRU i: = 1,n EXECUTĂ [eglculează media generală a elevului îl: ATRIBU' B 
S$.-0; PENTRU j-1m EXECUTĂ. S-S t NOTE, SFPENTRU ^ ATRIBU:E 


“MEDII; -S/M SFPENTRU PENTRU j: =1,m EXECUTĂ 


EA | PAR(,NUMEO) SFPENTiU 
“CHEAMĂ  ORDINE(n,NOTE,O); CHEAMA TIPAR(n,NUME,O) S 
CHEAMĂ ORDINE(n.MEDII,O); CHEAMA TIPAR(n,NUME,O) SFALGORITN- 

A Tot privind claritatea scrierii algoritmului, sé recomandă ca denumirile variabilelor 
A t ` » D 4 Nc 


să fie astfel alese încât să reflecte semnificaţia acestor variabile [Led7. 
Un alt mijloc de a mări claritatea textului unui algoritm consti în ; de 
: comentariilor în text. Comentariile sunt texte explicative jache Wes See Epi 

propoziţii Pseudocod $i se consideră că nu fac parte din algoritm. Au rolul de a ex lica 
cititorului anumite părți din algoritm. Am spus deja că în proiectarea algoritmilor lolos ol 
propozițü nestândard care vor fi pe parcurs înlocuite cu propoziții standard. E bine ca Aceste 
propoziţii să rămână în text sub formă de comentarii. SE 


Y Referitor la faza de codificare intr-un limbaj de programare a unui algoritm obţinut 
, In urma une: proiectări structurate se cere respectarea structurii acestui algoritm, ceea ce este 
posibil şi uşor de realizat dacă limbajul de programare are structurile de calcul respective În 
acest caz programul va fi o copie fidelă a algoritmului proiectat. Dacă însă limbajul de 
programare nu are toate structurile de calcul necesare, cum este cazul limbajului Fortran 
"standard, traducerea nu poate respecta algoritmul proiectat. În acest caz se recomandă 

traducerea algoritmului cu respectarea unor reguli de traducere a propoziţiilor Pseudocod . 

: [Fre83, Nic75], reguli care respectă cát mai fidel structurile elementare de calcul menţionate. 


Et -- Tot mai mulţi autori recomandă reguli, unele chiar rigide, ce trebuie respectate în 


_ proiectarea 
Ric[80]). 


` 


"Regula generală . 


Pentru fiecare aplicatie alege 
cuvintele cheie folosite (pentru =- 
variabile, funcţii, module,etc.) cát ` 
mai sugestive EE 
în autodocumentarea programului a se 
scrie numele celor care au elaborat 
modulele, sau care au făcut ^ .- 
modificări ulterioare 
Pe timpul întreţinerii aplicației, 
numerotează versiunile şi descrie 
prin comentarii fiecare modificare. 
REES S SE E 
Lungimea: maximă a unei funcţii sau 
proceduri este de 50-100 Linii 
US 


(instrucţiuni) : 
S pes SS X 
Respectă structurile fundamentale de 
calcul menționate. Ieşirea dintr-un - 
modul se face în ultima linie 7 
Cinstructiune). Sia Soo I OSA 
Evitá încuibarea unei instrucțiuni If. 
de mai mult de trei ori, prin - ^. 
folosirea instrucţiunii Case ^ —- — 
Evită modificarea contorului intr-un , 


y 


- f'cictu "pentru ^^ a SEH 
um zace SE S 
s CS EH Si 


operațiile de intrare/ie$1 
Verificá corectitudinea datelor de ` 
ántrare imediat după efectuarea 


Concepe- module SE 


intrărilor d 


şi codificarea algoritmilor. Astfel de reguli se pot vedea în tabelul 1.12.1 (după 


2S 
=> Eu 
“Rezultat 
x ai » 
= se măreşte Lizibilitatea textului 
— se eliminá eventuale confuzii 


|- se reduce timpul necesar alegerii 


denumirilor -folosite. 


-= creşte responsabili 
lucrează ^. . ta 
o, legătură mai rapidă cu 


tatea celor care 


- e asigurată 
cei care au conceput modulele 

- se asigură informațiile necesare. 
pentru înţelegerea naturii şi motivelor 
modificărilor a E 


SE se Limitează complexitatea unui 
- |'sdbalgoritm respectiv subprogram 


H- fiecare. structură de calcul are o 


singură intrare şi o singură ieşire - 
ADI TII A ee Ea a E : a ORALE 


= se măreşte claritatea programului 


= 


— se evită. eventuale erori greu de 
depistat. : Ñ ` 


structuri repetitive - A 
- izoleazá modulele care cer schimb de 


-|- se respectă semantica acestei 


“informaţii cu exteriorul 


pom i CAPITOLUL 2 


- 


4 Y 
A | 


| PRODUSE PROGRAM SI OBŢINEREA LOR 


D i n A 
D 


12.1. PROGRAME ŞI PRODUSE PROGRAM 


g program. - 
Vom încerca, de asemenea, sz 
1ce definesc calitatea acestora 


| KE ; ATUM 

În această secțiune ne vom ocupa cu definirea noțiunilor d i 
PR i Satelit pisat E Azi SE or de program și pro 
făcând o incursiune în activităţile specifice industriei de programe. A EE TAEA 


` facem o clasificare a produselor program si să definim câţiva factor 


` + 


2.1.1. Servicii specifice în informatică (oro 
„A Prin sistem informatic înțelegem un sistem ale cărui elemente interdependente sunt: 
echipamente de tehnică de calcul şi produse program; el are'o funcţionalitate bine precizată. . 
Serviciu informatic inscamná una din următoarele activităţi: ` - 2 s 
: - evaluare a cerinţelor şi a.performanţelor; | — ^ NS 


S - analiză şi specificare a cerințelor; ee 
proiectare tina an atace vata op S ADS Ada Mv 


ee livrare: Ns 
- instalare; ^ 


- întreținere; 550 - i 
ia Sa Consultanţă, o o e Se ee a e 
- toate privind sistemul informatic în ambele sale componente, şi : 
T ‘instruire; - Xs E E SAR SA 3 EE 
„= perfecționare; |. deus 
: "N asistență tehnică | | ^ ^ ao Ă 
acordată utilizatorilor sistemului informati SE S 
| 2.12. Profesii sp S SE 


` Putem discuta cel puti calculatoruleste obiectul san... 


da ji x S 
A ei e RA RS SS A N 
2 Y ` LUSIT x SAN SA SX NE See GE 5 : 
.,- utilizatori E, RR SAPE SER SERIEN S ES e ER 
EE EE ncţie de obiectul muncii lor şi de . 
„Aceste profe SNC A PS 
E Zei 7 A P uu ae e ee Pis à RN 


` poziţia pe care calculatorul ó ocupă în activitatea pe care o desfăşoară: 
- constructori de calculatoare şi de aplicaţii; 
utilizatori de calculatoare și de aplicaţii; 
- intermediari între primele două categorii. or] 


i Ultima categorie cüprinde profesiile implicate în comercializarea produselorinformatice 
(hard si soft) si în activităţile de întreţinere a sistemelor informatice şi de instruire a utilizatorilor 
acestora, 


Persoanele din adouacategorie;cea mai numeroasă, utilizează calculatorul ca instrument 
în desfăşurarea activităţii lor cotidiene (la serviciu sau acasă), într-o mare varietate de domenii. 
Caracteristica principală a interacțiunii lor cu calculatorul constă în: 

“e - cunoaşterea comenzilor sistemului de operare; 
- utilizarea unui program comercial pentru: 
e - editári de texte; 
- aplicaţii de. gestiune; 
- proiectare asistată de calculator; 
- calcule statistice; EE 
- prelucrări de tabele, etc.; 


(ştiinţifice, de gestiune) de mici dimensiuni. + 


- utilizarea unui limbaj de programare pentru rezolvarea unor probleme curente ` 


! 2 - ^ Primacategorie, mai puţin numeroasă şi, în general, extrem de specializată, este formată - 


2 din constructorii de calculatoare şi de realizatorii de aplicații (produse program). Includem în 


această categorie; inginerii ce proiectează noi tipuri de calculatoare, informaticienii carerealizează ` 
"aşa-numitul soft de bază (din companiile producătoare. de soft), cât şi cei ce produc aplicaţii 


| 3 comerciale dedicate unui domeniu îngust sau acordă consultanță in evaluărea, achiziționarea și- 
- utilizarea sistemelor informatice, Producătorii de soft se împart la rândul lor în analişti, proiectanți 
şi programatori. Carăcteristicile principale ale produselor soft realizate de ei sunt următoarele: 
„= se comercializează împreună cu documentaţii de utilizare şi au asigurat service; 


- sunt realizate în limbaje de nivel înalt, cu interfeţe utilizator simple si exploatând la - 


e —.- maximum caracteristicile calculatoarelor pe care sunt implementate; 


.. - sunt de complexitate medic/mare. ` xm 


- 2.1.3. Programe mici, programe màri .— > > 
-În capitolulprecedents-a dato clasificăre a programelor după dimensiunea lor, măsurată 


„punct de vedere: cela utilității tii a a : 


d $t 7 Ai auf Y Së Ze 1 vt v H E DES? vi ofesionisti şi în activitatea 
Prima dintre ele o întâlnim des în instruirea viitorilor informaticieni prole a 
utilizatorilor de calculatoare, iar a doua (produs program) când discutăm de rezultatul muncii 
realizatorilor de produse soft, ` — te SNR NEST 


id A SPERO ON. y EE 
e ambele accepţiuni, prin program înţelegem O succesiune de instrucțiuni scrise intrun, 
M limbaj See que du EUN. sau.in format executabil (program executabil) care este 
stimat rezolvării unei anümite probleme. În instruirea Jo liz 
f SCC DECH familiarizării cu algoritmii, limbajele Şi metodele de programar caes 
învaţă, De obicei, astfel de programe sunt de mici dimensiuni, fiind dedicate rez uni 


oeh 


rin numărul de linii sursă, În cele ce urmează, vom discuta noţiunea de program dintr-un alt 


oe pot distinge două acceptiuniale noțiunii de program: propriu-zis si produs program. 


În instruirea lor, viitorii informaticieni realizează. ` 


probleme simple (sortarea unui tablou de numere, parcurgerea unui arbore etc.). Utilizatorii de 

5 c deis care cunosc un limbaj de programare pot Şi ei să scrie programe pentru a rezolva 
verse probleme cu care se întâlnesc în activitatea lor profesională, unele chiar de dimensiuni 

mari. Ìn general, aceștia sunt atât realizatori cât şi utilizatori (de obicei singurii) ai acestor 

programe. De asemenea, de multe ori un program astfel scris are o unică utilizare, fiind dedicat 

unei probleme particulare. Prin urmare, în această accepțiune a programului, utilizatorul lui este 

"Şi analist; şi proiectant, si programator. În literatura de specialitate întâlnim termenul programming 
in the small, programare pe scară mică, ce reflectă esenţa acestei definiţii a programului. 


; Noţiunea de produs program (care va fi notat în continuare prin PP, termeni similari 
Bind: aplicaţie, pachet de programe, produs informatic, sistem soft sau pe scurt sistem) referă 
rezultatul muncii informaticienilor de profesie, producerea sa având un caracter industrial 
(produsul program este rezultat al industriei de programe) cu“următoarele particularități: 

- PP este destinat mai multor utilizatori independenţi (care-l pot cumpăra), + 
- cea mai costisitoare etapă din ciclul de viaţă al PP este cea de întreţinere; 
„= PP este în general de complexitate medie/mare; 
- PP este rezultatul muncii unei echipe; xs $ SS 
„+ = PP are o documentaţie şi există posibilitatea învăţării modului său de utilizare (se 
ecce Cursuri, există grupuri de utilizatori care promovează respectivul 


ză 


„> Realizarea unui astfel de produs program presupune colaborarea între mai ‘faulji 

specialişti, de profesii diferite: utilizatorii programului, analiştii, proiectanții, programatorii si cei 

cese ocupăcù comercializarea, instruirea în utilizare şi întreținerea produsului informatic. Fiecare . 
dintre aceste categorii de specialisti isi are rolul sáu determinant într-una sau mai multe dintre ` 


etapele ciclului de viaţă al programului. Există PP cu domeniu larg de aplicare (generale) şi PP 
" elaborate la cerere, cu un domeniu de aplicare mai îngust. Termenul programming in the large, 

programare pe scară mare (introdus de DeRemer în 1976) reflectă complexitatea activităţilor de 

realizare a unui astfel de program. - «t Ee 


E Deosebirile între aceste” două. accep[iuni alè noţiunii "de program vizează deci — 
- următoarele: - ^: ^ — M qr d] ^ EN 
- dimensiunea (complexitatea) problemelor rezolvate; = 


fesionăle implicate în activitatea de realizare; 


& 


- numărul de persoane şi categorii pro 


distribuire şi utilizare; ^ = - o 

- disciplina activităţii de realizare; = m | 
. - ponderea activităţii de întreţinere în ciclul de viaţă; 3 1 
2 cerințele de calitate; e «9. 0 


- aspectele comerciale şi de instruite i 0 Do RAE POPE 


În cele ce urmează à, prin program vom înțelege produs program. MN 
S Cn 2:14. Cláse de produse program ` 3 GE Ee E 

EE Ee SE pie clară de realizare 

ntru realizarea unui produs program este necesară o metodologie lizare 
a lui şi Sieten precisă a etapelor din ciclul de viață al acestuia. O cerinţă naturală ech 
metodelor de construire a produselor program Arie SE ee e 
i ` Altfel o metodă orientată spre un limbaj Ce mi l vea 
EE deoarece nu se va potrivi cu alte limbaje, ce au un alt model semantic de 
bază. FIAT D. ene : A 


i 
D REESE 
D D 3 


^ 


Metodele se pot restrânge (particulariza 
Rumbaugh et al. [Rum91] identifică următoarea clasificare a 
prelucrărilor (transformărilor) efectuate de acestea şi dup 
cu mediul extern. Asemenea tipuri de prelucrări sau programe sunt: 


) pentru un anumit domeniu de aplicare. 
e produselor program, dupá tipul 
á intensitatea şi frecvenţa legăturilor 


Prelucrare batch (pe loturi): transformare de date executată odată 

pentru un întreg set de date de intrare; . : 

Prelucrare continuă: transformare de date executată continuu cát timp sé modifică intrarea; ` 

Prelucrare distribuită: prelucrare caracterizată de latenţă în comunicaţie; 

Programe cu interfaţă! interactivă: programe aferente. sistemelor dominate de interacțiuni 
externe; VEA 

Programe de simulare dinamică: programe ce simulează obiecte evolutive din lumea reală; 

Programe în timp real: programe aferente sistemelor domiriate de restricţii stricte de timp; 

Programe de gestiune a tranzacţiilor: programe cé ~ realizează memorarea şi actualizarea 
volumelor mari de date, incluzând adesea accesul concurent din diferite locaţii fizice. 


(printr-o singură trecere) 


2.1;3. Calitatea produselor program 


` Amvàüzut cá produsele program sunt acele programe de calculator realizate şi distribuite 
în regim industrial. Ele sunt rezultatul activităţii industriei de programe. Obiectul ingineriei soft 
(software engineering) este găsirea mijloacelor de obținere a produselor program de calitate. 
` Calitatea produselor program. se definește ca o compunere a mai, multor: trăsături 
(factori). McCall [1977] împarte pentru prima dată aceşti factori de calitate în factori externi si 
factori interni. Atributul de intern sau extern se referă la industria de programe; un facfor este 
intern dacă el este detectat de persoanele implicate în procesul de elaborare şi întreținere a 
produselor program (analişti, proiectanți, programatori). Spre deosebire de factorii interni, cei 
externi, proprii exteriorului acestui proces, sunt palpabil pentru utilizatorii direcți ai produselor 
program, pentru cei care le comandă sau lé comercializează. În ultimă instanţă, factorii externi 
contează, ci contribuind la succesul unui produs program. Pe de altă parte, este clar că obținerea ` 
“trăsăturilor externe, de calitate este condiţionată de. satisfacerea factorilor interni, proprii 
“` procesului de dezvoltare a produselor program: = Ee 5 


iu Bortrand Meyer [Mey88] distinge 10 factori externi de calitate pentru aceste produse 

. program: Aceştia sunt^ ` SUSPEND i pee i 
- corectitudinea: satisfacerea completă a ceribţelor, pe 
“- robustețea: funcţionarea corectă chiár şi în condiţii anormale; S i 

NES - extensibilitatea: uşurinţa de adaptare la schimbarea specificațiilor; - 
SCH ` ` reutilizabilitatea: posibilitatea folosirii (integrale sau parțiale) a produselor program 

S la noi aplicati.. SE : is i CS pe 
` — compatibilitatea: combinarea facilă cu alte produse ech SS 

Z Gester buna folosire a resurselor ed de calcul (procesoare, memorie internà 

“si externă, dispozitive de comunicare); ^. - E ` Se S 

ortabilitafea: irita transferării în alte medii hard (alte configurații de calcul) şi 


soft (alte sisteme sau suprafeţe de operare); SH AS 

S S EE uşurinţa în elaborarea procedurilor de acceptare (validare) şi: de 
€ SE f 'depanare; S ; NOE ZS d S 

- integritatea: protejarea componentelor produselor program (programe, date, 

` documente) la accese şi modificări neautorizate;. SERES Š Sua 

- ușurința în utilizare: interfaţă utilizator prietenoasă, uşurinţă în: învățare, p 5 


Se 


" i * wi ` N ` N 
- E NA dét Y 


x 


pregătire date, interpretare rezultate, recuperare din situaţii de eroare 


X Factorii interni de calitate sunt strâns legati 
elaborare a produselor program. În mod esenţial, rep 
d UR metodele de analiză şi proiectare a produselor program; + 
|. 7 facilităţile oferite de limbajele de programare folosite la implementare; 
, - aspectele organizatorice ale industriei soft. 


a intimă a procesului de 


Între factorii interni de calitate menţionăm: 
- modularitatea: structural, produsul program este alcătuit din module, ce formează 
i o arhitectură descentralizată, 
SĂ - documentarea completă: existenţa unei documentaţii clare E adusă la zi pentru 
fiecare fază a ciclului de viaţă al programului. — ^- 
22. PROCESUL DE DEZVOLTARE A PRODUSELOR PROGRAM 
: 1 VESTE A C CL : - 
Desc Crearea de noi produse prógram este un proces complex, a cărui structură cunoaşte 


o continuă perfecţionare. Dacă la începuturi construirea de produse program era considerată . 
^O artă, astăzi se: cunosc diverse metode şi tehnici de realizare a produselor program. Desigur, . 
metodologia de elaborare'a produselor program a cunoscut o evoluție continuă, inclusiv (sau, 

_ “poate, cu atât mai mult) în zilele noastre. Complexitatea crescândă a sistemelor soft realizate, 
pe de-o parte, si noile generaţii de limbaje de programare, pe de altă parte, au influențat 
‘dezvoltarea de noi metode de realizare a programelor: programarea structurată, programarea 
-modulará, brogramarea orientatá pe obiecte. Procesul de creare a produselor program este 

- constituit din două faze mari: modelarea si concretizarea. Cà o remarcă generală, se observă 

creşterea continuă a ponderii modelárii;crestere justificată de cerinţele de calitate discutate ` 
ET EE 


SA 
KEEN 


22.1. Modelarea ` 
"Orice metodă de dezvoltare începe cu precizarea; descrierilor abstracte, numite 
^U. + modele ale sistemului supus analizei sau proiectării. Pentru descriereaunui model se foloseşte 


o anumită notație. Evaluarea unei metode înseamnă. discutarea modelelor pe care ea le 
construieşte şi a notaţiilor (documentafiilor) folosite. O primă cerință asupra modelelor se. - 
„poate formula astfel: mulțimea de modele trebuie să alcătuiască o descriere completă, şi 


consistentă. | .. ^. 


i 


SC? d EE Sinis VU ES ZE x NN 5 PUE SEN SCH SC A il ide: 
^, Se disting douá ti uri de modele: fizic | logic. Modelul fizic este concret şi legal 
Es atructura actüala asistemului soft. Tipic,el operează cu module de codsi eer 
|“ “1ogie contine abstracţiile cheie a e sistemului. Modelele logice; se împart în mod e er sa 
p case conţin descriercastructurii sistemului, si modele dinamice, care descriu pup pc 
temporal si funcțional al sistemului. Un alt criteriu de. tlasihicare este. aria de a e 
“modelului: întregul Sistem sai empor a ainu ds 3 P ded 
N adică (modul. clasă sau pachet) sau poate ti un subs „În situaţiile ; easi ` 
; ; atomică o E mai multe. modele, se pune problema stabilirii umor reguli de . 
verificare a consisten(ei între respectivele modele. aod ene NES 


PURA E ee e 


2.2.1.2. Fazele modelării l m 
Ín aceastá sec[iune se identifică unele dintre activităţile ce constituie procesul 
oltare a softului. Multe dintre metode acoperă diferite părți ale ciclului de viaţă, nu n 
analiza ŞI proiectarea, Prin urmare, este mai potrivit să se descrie o metodă i ter 
activităților de dezvoltare pe care le asigură. Aceste activităţi pot fi combinate în diverse 
pentru a realiza un model de proces particular, de exemplu modelul spirală. 


Li 


dezvolta de- 


menii 


Termenul praiectare este folosit în multe acceptiuni de autorii diverselor metode, aga ` 


încât multe metode ce se afirmă că sunt metode de proiectare includ de fapt și aspecte ce (in de 
analiză şi implementare. Pentru scopurile noaste folosim următoarele definiţii: 


B Analiza are ca scop construirea modelului logic al sistemului şi al mediului său. În această 
etapă se pune accentul-pe descrierea proprietăţilor şi nu pe descrierea mecanismelor care le 
implementează. 


Proiectarea este faza în care sistemul-ce urmează a fi realizat este despărţit de mediul 
său. Modelele logice produse în faza de analiză sunt rafinate şi concretizate succesiv, obținându-se 
modelul fizic. Accentul se pune pe realizarea proprietăţilor structurii sistemului. Putem distinge 
două tipuri de proiectare: `. S EE : ; ; , 

- nivelul produsului program): stabilirea arhitecturii acestuia, adicá a 


- de ansamblu (| 


_ “modulelor şi a dependenţelor dintre ele; i ^4 
` -'de detaliu, (la nivelul modulului): proiectarea structurilor de date şi proiectarea 


„> operaţiilor. 


“Implementarea codifică modelele logic şi fizic folosind un limbaj de programare 
particular. În acest punct al procesului, sunt deja definite atât structura cât şi comportamentul 
sistemului. Accentul se pune pe codificarea proiectului utilizând primitivele (tipurile de date şi 

instrucţiunile) limbajului de programare ales. — ,.— => EE ; 


CG 3 cu ag - 


18202. Modularitatea - factor esenţial de'calitaté ` 


j 


- Am discutat în primul capitolul importanţa documentării produselor program. Deoarece 


procesul de elaborare a acestora este o muncă de echipă (pot exista echipe distincte în fiecare fază 


a ciclului de- viață), existența documentaţiilor puse la zi este o condiţie sine-qua-non pentru 


Obţinerea factorilor interni de calitate: > OE 
^. ^ în continuare vom discuta primul dintre factorii interni de calitate, modularitatea, sub o 


K p EPA A PASE ES CILE H E 3 : D Set R AIC Sem. 2 
În capitolul I s-a definit programarea modulará: construirea de bec > C: 

- "ansambluri dee (elemente), numite module. Ambii termeni sublinia au cunoscut o 
EE evoluţie; în ceca ce priveşte semnificația lor. Be p n 


“Aşa cum s-a arătat în capitolul precedent, term rot i ui 
MO i restrâns si unul larg. Definiţia de mai sus corespunde sensului larg al Serres 
To sensrestrâns, prin programare modulra se lee EE 

“a programelor, deci strict legată de limbajele de programare şi de taci tati Sn larizare p 
e SE le oferă. B Stef nu;sé poale vorbi de o coditicare modulară dacă proiectarea nu 
ER făcut modular. . EA S NAR CENA a UR SERIA 


/f5 


H 


211 
LZ 


SEO 


umai - 


moduri 


nul de programare modulară are dout ` 


Terenul du FER sp o ERAY ERI 
program: e modul este folosit în două faze diferite ale ciclului de viaţă al produsului 
V 


- In proiectare: modulul este un element al arhitectu 
x de proiect, sau modul logic; 

- în implementare: modulul este o unitate sintactică autonomă 
` „vorbim de modul de program sau modul fizic. : 


rii produsului program, numit modul 
compilabilă separat; 


' 


2.2.2.1. Cerinţe ale modularizării 


indul n DM S modularitatea este factorul intern 'eseriţial de calitate. Discutarea 
j privitor la cerințele impuse asupra: ' 
- metodelor de analiză și proiectare; ; 
- modulelor proicctate, atât pe ansamblu cát și în detaliu. 
` 1 H Li 
3 În faza de analiză, sistemul, considerat "Cutie neagră” este discutat împreună cu mediul 
său (lumea exterioară unde acesta funcţionează), identificându-se legăturile sale cu exteriorul 
(interfața externă: intrările si ieşirile) şi funcționalitatea sa. Interfața si funcţionalitatea sunt 
concretizate în ceca ce am numit model logic al sistemului. În faza de.proiectare, când sistemul 
este despărţit de mediul sáu, această "cutie neagră" trebuie deschisă, identificându-se prima dată 
părţile componente (subsistemele, modulele) - la proiectarea de ansamblu - si apoi discutándu-se 
în detaliu fiecare modul în parte. Prin urmare, activităţile de analiză $i proiectare vor produce” 
versiuni succesive, din ce în ce mai detaliate şi mai concrete, ale modelelor logic şi fizic. Nu putem 
“să trasăm o barieră distinctă între fazele:de analiză şi proiectare, considerând cá modelul logic este 
complet la terminarea analizei. Dimpotrivă, considerăm că în faza de proiectare se continuă 


„rafinarea modelului logic, concomitent cu dezvoltarea celui fizic, . - 


Metodele.de proiectare trebuie să asigure satisfacerea urmátoarelor cerinţe (principii, 
criterii) ale modularità(it; = = == E OU 
"= descompunerea modülará: o problemă. P se poate descompune in subprobleme . 
Ded - ^. (module); -= ACA CHR a ae a E 
à - compunerea: modulară: elementele soft deja existente se pot -combina pentru a 
contribui la rezolvărea altor probleme; « ` EE E 
-- “protecţia modulară: arhitecturile de module realizate restrâng propagarea unor. ` 
„condiţii anormale, efectul acestora limitându-se la modulul în care ele apar sau, 
in cel mai ráu caz, la modulele legate de SCC b gere c e 3 


i CRT ZER 
D 


| - Pe de altă parte, modulele rezultate din proiectare trebuie să îndeplinească două cerințe 
generale; i oo uut m pre CELINE al EE E rum 
- înţelegere uşoară: să aibă un înţeles „de. sine stătător ele însele, pe cât posibil fără : 
„consultarea altor module; = ^ SE 
E independenţă la modificările făcute în exteriorul lor: modificările mici într-un modul 


“să nu afecteze celelalte module; Meyer numeşte această cerinjä continuitate 
modulară. . Ape pa T Su A Raza Sa e : 


d Vu SZ SE : SE EE EN ; à 
În plus, la proiectarea de ansamblu, când se idénfifică modulele şi se stabilesc interfețele 
(legăturile) dintre cle, trebuiesc respectate două cerinţe specifice: 3 
= comunicare minimă între module; DS EES 
CR arhitectură descentralizată a sistemului soft. . Y i 
Za D j N AN 


vm coser de voalare Al modeluluiilogi odulul apare ail, ca o entitate de sine 
Din punctul de vedere al modelului logic, modulul ap: | o entitate x 
stătătoare, [oală din două componente: stare:(în general proprie modulului) şi servicii oferite 

^ - ^ y i Kë 1:135» Geh m H d AË z N SCENE x 


N 


exteriorului. Comportamentul modulului este for 

inein(eles, anumite servicii (sau chiar toate) sunt 

ı modulul este O unitate de program sursă, în care: 

- tării (din modelul logic) ti wor corespunde structuri de date. 
; Care conţin valori ce caracterizează starea; 

- serviciile se realizează prin apeluri de proceduri (vom numi procedurile operații). 


După disponibilitatea serviciilor, avem două categorii : client și i 

i gorii de module: client şi furnizor. Un . 
modul A este client al unui modul B dacă el foloseşte servicii ale modulului B. Reciproc, se spune 
că B este modul furnizor pentru A. i S 


mat din totalitatea serviciilor oferite de acesta; 
influențate de starea acestuia. În modelul fizic, 


, numite variabile de stare, 


? 


Un modul comunică cu exteriorul său (deci cu alte module) prin ceea ce numim interfaţa 
sa, care specifică serviciile disponibile în exterior. Cealaltă parte a modulului éste interiorul sáu 
(numit $i parte privată, spre deosebire de interfaţă care este partea publică). Cerinta comunicării 
F între module se referă la proiectarea interfetelor dintre module şi cuprinde următoarele 
o: 
> = număr minim de legături cu alte module (principiul interfetelor puţine); 
- debit minim de informatie schimbată cu alte module (principiul interfeţelor mici); 
- informaţia. din interfața unui modul este disponibilă tuturor celorlalte: societatea 
modulelor este. democratică, neexistând simpatii şi antipatii (principiul 
- . ^ interfeţelor publice); LN i A 
-- protejarea informaţiei interne modulului (principiul ascunderii informaţiei private): 
à - -accesul din exterior la datele private se Dee numai prin intermediul serviciilor 
din interfata modulului. * Pin UM A Ny. OEC 

- A doua cerință, arhitectura descentralizată, se adresează proiectului logic de ansamblu. 
Într-o asemenea arhitectură, nu există un modul principal, fiecare modul în parte dispunând de 
autonomie maximă (posibilă). Autonomia unui modul se poate defini astfel: într-o situație data, . 
comportamentul modulului este influențat decisiv de starea zg. O asemenea, abordare elimină 
dependentele temporale între module (două module A si B sunt într-o dependenţă temporală 
dacă ele trebuie executate într-o ordine prestabilită: întâi A şi apoi B sau invers). Revăzând 
clasele de produse program enumerate în 2.1.4., putem afirma că o asemenea arhitectură este 
adecvată tuturor, exceptând clasa programelor batch (pe loturi), care pretind o anumită 
dependenţă temporală a. operaţiilor efectuate. Din punctul de vedere al proiectului fizic, 
arhitectura descentralizată impune ca modulul să fie o unitate de program distinctă, compilabilă 
-- separat. 


Proiectarea de ansamblu identifică modulele după serviciile oferite, considerându-le 
drept"qutii negre”, Următoarea fază, proiectarea de detaliu, are ca obiect modulul, ignorând locul 
-]ui în arhitectura sistemului. În această fază, atenţia proiectantului este îndreptată asupra poss 

-de concretizare a serviciilor pe care trebuie să le ofere modulul, punándu-se accentul pe modelul: 
“fizic, Activităţile proprii acestei etape a proiectării sunt: E 

m A ecd structurilor d- TE (corespunzătoare variabilelor de stare); 
- proiectarea algoritmilor specifici operaţiilor pe aceste structuri de date (care. vor 
corespunde serviciilor). Se : USES 


; ; “Rezultatele proiectării de detaliu sunt modelele logice şi fizice ale modulelor, Aceste 

~: modele trebuie să satisfacă dană cerinţe: generalitate si minimalitate. ES 

(Lp 7 în Generalitatea este o condiţie majoră pentru reutilizarea modulului. Ea se obține piin: 
|^: abstráctizarea datelor, genéricitate si pólimorfism. : 


Ld 


Abstractizare 

se realizează: 
- proiectarea mài multor operaţii pentru o aceeaşi structură de date: 

ju? Proiectarea modulului independentă de contextul în care el se utilizează 

La nivelul proiectării fizice,.al implementării, unei abstractizări (văzută ca proiect lo zic) să-i 

corespundă mai multe realizări (proiecte fizice), toate echivalente semantic, dar care difer TY 
- folosirea de reprezentări diferite ale structurii de date; xa 
- proiectarea de algoritmi diferiţi pentru aceeaşi operaţie. 


a datelor va fi discutată în capi ător. În linii mari, pri 
al tin capitolul următor. În linii mari, prin abstractizare 


m “Termenul de genericitate este folosit în înțelesul de parametrizare a tipurilor de date 
Există situații când un același algoritm se aplică identic (la nivelul conceptual) asupra unor 
structuri de date diferite: De exemplu, algoritmul QuickSort pentru tablouri de: numere întregi 
numere reale, şiruri de caractere, inregistrári cu o anumită structură etc. este același conceptual; 
ceea ce diferă în codificarea lui sunt aspectele legate de manipularea si compararea elementelor 
tabloului. Prin urmare ar fi de dorit să se poată concepe o operaţie (procedură) generică, care va 
-avea între parametri tipul de bază alstructurii de date considerate. Proiectarea operaţiei se va face 
operând cu acest tip parameirizat.. - : M 


„i. Conceptul de polimorfism va fi discutat în capitolul IV. El implică independenţa 
serviciilor de reprezentare sau algoritm (apelul unei operaţii trebuie să fie acelaşi, independent 
de reprezentarea aleasă sau de algoritmul folosit în implementare). Altfel spus, când un client are 
nevoie de un serviciu oferit: de un furnizor, el nu trebuie să, cunoască decât modul cum poate 
obţine respectivul serviciu (modul de apelare al acestuia, specificat în interfața furnizorului); în 
plus, ceea ce este specific polimorfismului dinamic, dacă furnizorul oferă mai mulie servicii 
similare (care diferă prin reprezentăre sau algoritmi), apelul lor trebuie să fie același; alegerea 
serviciului adecvat nu cade nici în sarcina clientului, nici a furnizorului, ci a mecanismelor interne 
ale limbajului de programare şi este cunoscută sub numele de legare dinarhică, concept discutat 
de asemenea în capitolul IV. > : Ke SIS : 


Cea dea doua cerinţă, minimalitatea, înseamnă aici evitarea redundantelorin proiectare. 
Având în minte discuţia mijloacelor de oblinere a generalităţii, putem afirma că în loc de un singur 
modul (cu o stare şi un comportament bine precizate) se pot concepe ierarhii de module (cu 
aceeaşi funcţionalitate) care să acopere pe de o parte multitudinea alternativelor de implementare 
(privitoare la reprezentări si algoritmi pentru operăţii), iar pe de altă parte să precizeze o singură 
dată caracteristicile comune ale modulelor proiectate. Realizarea cerinţei de minimalitate este. 
` strâns legată de conceptul de moştenire, care va fi discutat tot în capitolul IV. 
2222. Modularizarea şi calitatea produselor program ~ 


“` Cerințele si'mijloacele de proiectare a modulelor discutate în secţiunea precedentă au 


o influenţă decisivă asupra factorilor de calitate a produselor program. În-continuare, vom discuta 


pe scurt această influenţă asupra unora dintre factorii de calitate. 3 


; Fiabilitatea produselor program (corectitudine. + robuste(e) este MXN e eren 
privitoare la protecţia modulară şi la comunicarea minimală între ap M opa SA uor 
condiţii anormale apărute într-un modul M este, restrânsă cel mult a mo ele ge der 

` interacționează (datorită protecţiei modulare), al căror număr este minim p | 

imbarea specificaţiilor unui produs p ins 
a EN GER inclusiv adăugarea de funcţii şi stru 
care măresc extensibilitatea produselor program menţionăm: Eu ` A 


x 


rogră înseamnă modificári ale funcţiilor si 
Wa icturi de date noi, Între factorii 


4 


P I d ? Zei) 


` 


UE 


er, 


` prih anumite convenţii, între care amintim: ` > - 


„produsului program în ansamblul său. SE 


„ciclul de viață al'acestuia. `: 


^ realizedzA: 


-- simplitatea proiectului (arhitecturii): o arhitectură simplă este î i 
, n ; ásimplá este intotdeauna m. 
: modificat decát una complexá; pee EAT 
- descentralizarea si autonomia modulelor, impreuná inui 
un ă: 
exces tue ni modulele fa preună cu continuitatea modulará: o - 
bar specificaţii va fi localizată într-un modul (sau în mai multe) 
: neimplicánd clienţii acestora;, ; 
- polimorfismul; dacă modificările nu afectează protocolul de „comunica 


ție (apelul 


serviciilor), atunci modulele client rămân neschimbate; t 


NE moştenirea: prin derivarea de noi structuri de date, cu comportamentul cerut de noile 
specificaţii, pe baza celor existente şi fără modificarea comportamentului celor 


* 


i. existente, nu vor fi afectate modulele client. 


S Reutilizabilitatea este un vechi deziderat al programării. Încă din anii '60 se considera - 
că realizarea ideală a produselor program ar fi o activitate de asamblare a unor module deja: 


. existente. Este evident că modularitatea softului este o condiţie sine-qua-noh a reutilizării. Între 
factorii ce îmbunătățesc ‘reutilizarea menţionăm compunerea  modulară, generalitatea, 


minimalitatea şi existența unităţilor de program distincte. Sec[iunea urmátoare va discuta pe larg 
legătura strânsă între modularităte și reutilizabilitate. CN E P 


Combinarea uşoară a programelor între ele (compatibilitatea) se poate realiza în general 
- -gntrár/fesiri standardizate; pi 
- Y structuri de date standardizate, = “7 = o 
-- interfeţe utilizator standardizate. © -= < EE ; 
Între cerințele asupra modulelor ce conducla asemenea soluţii menţionăm proiectarea modulelor. 
(care realizează operaţiile de intrare/ieșire, gestiunea colecţiilor de date, interfaţa utilizator) 
independentă de contextul de aplicare a lor. Evident, într-o asemenea abordare, compatibilitatea 
este influenţată de existenţa componentelor respective, care vor putea fi reutilizate. ` 


S 


` În afara factorilor majori de calitate (mai sus discutăţi), si ceilalţi factori de calitate sunt 


"influenţaţi de cerinţele impuse asupra modularizării, unii direct, alţii indirect. Astfel, eficiența 


poate fi stabilită după diverse criterii: timp, sau memorie şi după domeniul de aplicare sau clasa 
produsului program. Existenţa de proiecte fizice diferite pentru acelaşi proiectlogic (ce diferá prin 
reprezentări şi algoritmi) oferă o mai mare flexibilitate în proiectare şi, implicit; răspunde mai 
bine criteriilor de eficienţă alese. În altă ordine de idei, modularizarea îmbunătăţeşte gradul de 
verificabilitate a programelor, procedurile de testare, acceptare şi depanare putând fi realizate la 


: . nivelul modulului, în timpul implementárii acestuia (testarea de modul). Principiul interfetelor : 
minime simplifică, de asemenea, testarea interfejelor dintre module, reducând numărul de astfel 


^ 


de teste. În sfârşit, ascunderea informaţiei private modulului creşte gradul de integritate a 
: +“ Diseuţia de mai sus trebuie să 1a în considerare încă un aspect: factorii de calitate îşi 
dovedesc utilitatea în special în faza de întreţinere a sistemului soft; cea mai costisitoare fază din 


* 


D M 


` 223. Reatilizarea sofiului ` < : 


|n 


În secţiunile anterioare s-a afirmat că un produs program de calitate are o arhitectură 


/ modulará. Se pune întrebarea: unele dintre modulele ce compun un anumit program nu pà fi 


` folosite la realizarea altor programe? Am menţionat în secţiunea precedentă (când am discutat de ` : 


compatibilitate), cel puţin 3. clase de module in care este recomandatà reutilizarca, care 


! 


= operații de intrare-ieşire; 
- implementarea colecţiilor de date "clasice" (liste, tablouri, arbori, etc.); 
- gestiunea interfeţei cu utilizatorul. 


Termenul de reutilizare îl putem discuta ([Mey88]) în trei iuni 
em d y88]) în trei accepțiuni: pentru'modul 
ien eus şi pentru proiecte. În discuţia ce urmează, vom considera Haahi ca element d 


223.1. Locul reutilizării în procesul de dezvoltare a softului 


Diagrama din figura 2.2.1, preluată din [Kru90], ilustrează activităţile specifice procesului 
de construire a produselor program. În acest proces, abordat sistemic, intrarea este reprezentată 
de cerinţe, iar ieșirea de produsul finit, sistemul soft. Procesul este împărţit în 6 etape, care 
operează cu modulele ce compun programul în ansamblul'său. Totodată, procesul dispune de un 
depozit de componente (module) reutilizabile, care se îmbogăţeşte continuu. 4 


pentru un produs program. Faze 


^ 
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Figura 2.2.1. Reutilizarea si procesul de dezvoltare a softului: 


În diagrama amintită am precizat cu majuscule. etapele "clasice" ale ciclului de viaţă 
le de realizare a produsului program şi acţiunile efectuate sunt: . ` 


A. Identificarea componentelor (modulelor) produsului program PP, care înseamnă: S 
-. — realizarea modelului logic si fizic de ansamblu; ... - : 
—— stabilirea componentelor care trebuie proiectate; 
4 — stabilirea componentelor existente în depozit; — A 

B. Elliborarea componentelor noi ale PP, adică proiectarea şi iniplementarea acestora; 
C. Modificarea componentelor. extrase din depozit (dacă e nevoie), cu observaţia că 
modificările făcute nu trebuie să afecteze componentele existente în depozit; se . 

- recomandă ca reprbiectarea să producă o nouă componentă; —— Sa, 

D. Utilizarea componentelor la realizarea PP, atâta celor existente (nemodificate), cât 
„ “şi a celor noi sau reproiectate; `. ORE SE uS SR 

E, Actualizarea depozitului cu componentele noi şi cu cele reproiectate. În această 
viziune, procesul de construire a produselor soft este ciclic, iar dimensiunea 
depozitului creşte cu fiecare realizare a unui nou produs. În acest proces poate 


fi implicat un analist-programator sau o companie de soft. În ambele cazuri, cu 
cât numărul de produse program realizate este mai mare, cu atat dimensiunea 
depozitului de componente reutilizabile creşte şi, prin urmare, efortul de 


realizare a componentelor noi (etapa 2) sau cel de reproiectare a celor existente 
| : 


Pn CM j e Aa tă 


(etapa 5) este mai mic. 


2.2.3.2. Reutilizarea şi experienţa în elaborarea programelor 
in did Am vázut cà procesul de creare a produselor soft poate fi'considerat atât la nivel micro 
s P dps cát si la nivel macro (o organizaţie, compânie, echipă). Deşi ideea reutilizării 
ste veghe, punerea ei în practică nu este aga de simplă. Mai întâi o să discutăm o primă abordare 
a reutilizării, la nivelul programatorului. 
Să punem următoarea întrebare: — 


Cum proiecta(i şi implementa(i o: mulţime de întregi? 


Răspunsurile ce se 'obțin depind de experienţa subiecţilor (vechimea în activitate, limbajele de 
„programare cunoscute, numărul şi complexitatea programelor realizate) şi ar putea fi: 


1; un programator FORTRAN ar folosi reprezentarea mulţimii ca tablou, iar operaţiile 


e ar fi concretizate în subrutine; 
2. un programator Pascal ar avea mai multe alternative: 
a) folosirea tipului predefinit set (cu operatorii respectivi) dacă din specificarea 
j problemei n-ar rezulta că trebuie gestionate şi mulţimi cu mai mult de 256 
e elemente, sau, in caz contrar, 


S T. b) reprezentarea mulțimii ca tăblou sau listă inlán[uitá, cu operaţiile văzute ca 
proceduri şi funcţii; — A EE EHS 
3. un programator C ar putea reprezenta mulţimea ca tablou, listă înlănțuită sau sir de 
: biți, iar operațiile pe ea ca funcţii C; —— SE j 
EU 4. un programator Ada (începător), sau. Modula, sau Turbo Pascal ar scrie un pachet 
E Y S (modul, unit), în care ar pune împreună. reprezentarea aleasă (vezi 2) şi . 
operaţiile proiectate; 
5..un programator Ada cu experiență medie ar scrie un pachet generic, parametrizând 
tipul elementului mulțimii (în cazul nostru întreg), în ideea utilizării acestui 
2, pachet și pentru alte tipuri de date; - SE 
d -6:1n programator Ada avansat ar scrie o familie de pachete generice, cu diverse strategii 
de implementare, potrivite de folosit in diverse situaţii. (diverse criterii de 
eficienţă: timp sau memorie, eventual cu gestiune proprie a memoriei şi cu 
` “facilităţi.de lucru într-un mediu concurent); : 
7. un programator C+ + avansat ar. aranjă diversele implementări într-o ierarhie de 
"en S clase, cu punerea aspectelor comune in clase abstracte - C++ fiind un limbaj 
1 “orientat pe obiecte, apar noi forme de reutilizare prin posibilitatea de a deriva 
ACT noi clase din cele deja, existente» 


d 


225.3; Abordări ale reutilizării | i 


'- Putem distinge mai multe abordări ale termenului de reutilizarea unui modul. Aceste 
i abordări sunt influențate de evoluția limbajelor de programare ‘şi, în general, de evoluția 


kire metodelor de dezvoltare a produselor program, Respectând această evoluție, putem distinge 
A „etapele: UE EE / ; S 

d  — biblioteci de rutine, . 

Pa - pachete (module, unit-uri); , 

i - pachete generice; SE 


EE - clase. ' j : ry. 


Bibliotecile de rutine au fost si sunt unul di iabilitàtii mbani 
programare FORTRAN. Algoritmi dle ul dintre argumentele viabilităţii limbajului de 


1 n cele mai variate domenii izei ice 
preluaţi de echipe specializate de informaticieni (şi nu numai) UE EE a UE 
(subrutine, funcţii) FORTRAN, ce au fost incluse în biblioteci. Un utilizator al unei Si e 
biblioteci, cunoscând modul de apelare al rutinelor din ga (care înseamnă, conform termin logici 
: A m S EE SE 
introduse în 2.22.1, serviciile oferite de bibliotecă, ea însăşi fiind un furnizor), le và putea folosi 
pentru a scrie programe care să rezolve (numeric) problemele pe care le studiază. În general 
asemenea biblioteci ny conţin texte sursă, ci module obiect rezultate din compilarea acestuia. Prin 
urmare, utilizatorul nu poate vedea cum este codificat un anume algoritm, dec; nici nu-l poate 
modifica. El este doar un client al respectivei biblioteci; folosind serviciile oferite de aceasta. 
Programatorii experimentați pot să-şi creeze propriile lor biblioteci de astfel de rutine. 
Caracteristica esenţială a acestor rutine este că pun accentul pe algoritmi (operaţii), lăsând 
problema datelor pe seama utilizatorilor, care trebuie să scrie apelurile (parametrii actuali). în 
conformitate cu specificaţiile parainetrilor. formali. ; 

Pachetele (modulele) reprezantä nic pas înainte din punctul de vedere al reutilizării, 
în sensul că ele grupează, pentru o structură de daie considerată, operaţiile proprii acelei structuri. 
Termenul de pachet (package) este propriulimbajului Ada, în alte limbaje vorbindu-se de module 
(Modula) sau unit-uri (Turbo Pascal). In general acestea (pachetele, modulele, unit-urile) sunt 
unităţi sintactice independente ce conţin atât reprezentarea, cât şi operaţiile unui tip de date 
utilizator şi pot fi compilate separat. Între limbajele de programare ce posedă facilităţi. de 


AS modularizare menţionăm Modula, Ada; Turbo Pascal şi C 4 . Modularizarea în limbajele de 


l programare va fi discutată în capitolul următor. 


Atât rutinele, gât si pachetele se încadrează în ceca ce vom numi reutilizare de speța I-a: 
refolosire în alte prograime, fără posibilitatea modificării textului sursă. 


M 


Următoarea treaptă evolutivă în reuiilizăre este pachetul generic. Acesta este un pachet 


S (modul) parametrizat, de/obicei parametrul fiind tipul de date supus prelucrării. Astfel, în 


_ problema sugerată anterior (mulțime de numere întregi), tipul elementului mulțimii ar putea fi 
un asemenea parametru generic. Odată realizat un asemenea packet generic, din el se vor putea ` 
crea (automat), pachete specifice pentru diverse tipuri de date: numere întregi, numere reale, 

- caractere, şiruri de cáractere, tipuri de date utilizator, prin ceeace numim instartfiere a pachetului 
generic, înlocuindu-se parametrul generic cu un parametru actual concret; adică unul dintre 


` numele tipurilor de date enumerate. Vorbim aici de reutilizare de:speţa à H-a: folosirea. în 


programele utilizatorului de instanţe ale pachetului generic, prin particularizarea tipului de 
element, dar fără modificarea pachetului generic: Evident, este muli mai comod să se scrie un 
pachet generic, decât să se scrie câte un pachet peatzu arce tipde date. Limbajele Adasau C + + 
permit crearea de pachete (clase) generice; ee SS Xen 
S BEL RD e ITERUM PT BL urs ` S 
Abordările reutilizării descrise pâna acum. Gespen Ti s de praa TY a pere 
modificarea funcționalități modulului. În ambele situaţii, utilizatorul va putea torosi doar ace € 
operaţii pe careimplementatorül sau programatorul furnizor (al.bibliotecii, pachetului, pachetului 
" generic) le-a prevăzut, neputánd să modifice modulul prin definirea noilor operații de care aravea 


nevoie. Altfel spus, comportamentul modulului. este definit de implementator şi mu poate fi 


'/ schimbat de utilizator, care are deci un rol pasiv. 


Pasul uriaş în reutilizare este făcut de programarea orientată pe obiecte, care foloseşte 
moştenirea pentru a crea ierarhii de module (numite aici clase), în care Eege 
sunt atribuite părinţilor, iar cele specializate descendenților. Folosind o asemenea ierar 


A Y H d ace derivate tru 
2 i 1 áti i descendenţi (noi clase, numite clase deriv até), pen 
clase, utilizatorul o poate, mboga i cu pp de ți (noi cla: 


care el trebuie să precizeze doar acea 
Apare astfel reutilizarea de speța a III 


vorbi de o dublă reutilizare: pe de o parte clasele derivate mostenesc definițiile specifice 
comportamentului părinţilor (fără a mai fi rescrise); pe de altă parte, noua ierarhie realizată 
(îmbogăţită) este total compatibilă cu vechile sale utilizări (clasele existente în ierarhie nu au fost - 
modificate). De data aceasta programatorul client are un rol activ. Limbajele de programare 
orientate pe obiecte (discutate în capitolul IV) cunosc astăzi o dezvoltare puternică. 


parte a comportamentului care diferă de cel al părinţilor. 
-a: crearea de clase derivate, pe baza celor existente. Putem 


2.2.3.4. Factori ce influenţează reutilizarea 


„Putem distinge trei clase de factori care influențează reutilizarea, de natură 
organizatorică, metodologică sau care sunt strâns legaţi de limbajul de programare. Factorii 
organizatorici includ gestionarea depozitelor de componente reutilizabile şi politica companiilor 
producătoare de soft faţă de acest factor de calitate. Cei metodologici (in de mijloacele pe care 
metodele de analiză şi proiectare le posedă pentru realizarea acestui deziderat. În sfârşit, limbajele 
de programare pot să influenţeze reutilizarea prin mecanismele de abstractizare, modularizare 
şi cele proprii orientării pe obiecte pe care le posedă. Revăzând discuţia din secțiunea precedentă, 
printre aceşti factori enumerăm: : SE 

1. Disponibilitatea codului (sursă, obiect, biblioteci de rutine); 

2. Facilităţile de modularizare si abstractizare a datelor existente în limbajele de 
& programare; , 

3. Existenţa mecanismelor de genericitate; ~ 5 

4.'Orientarea pe obiecte, prin mostenire şi polimorfism; 

5. Existenţa unei politici de realizare a depozitelor de componente reutilizabile la nivelul 

companiilor soft; nce 
6. Experienţa şi abilitatea programatorului, proiectantului în general. 


Factorii 1 şi 5 sunt de natură organizatorică, pe când ultimul este mai greu de cuantificat: 
părerea noastră este că el depinde atât de instruirea şi autoinstruirea programatorului, cât şi de ` 
talentul acestuia în a surprinde aspectele generale într-un context particular. În.sfârşit, dar nu în 

cele din. urmă, metodele de analiză şi proiectare, şi limbajul de programare folosit la 
“implementarea modulelor au o importanţă deosebită, evidenţiată de factorii 2-4. 


12.2 3.5ăAvantajele şi costurile reutilizării + 


Reutilizarea softului are efecte benefice asupra industriei de programe: Între avantajele 
evidente, menţionăm: d 


- costurile de dezvoltare scad, efortul de proiectare fiind mai me ` SES. 
- "1 calitatea creşte: se presupune cá componentele reutilizabile funcţionează corset, — 
- se îmbunătăţeşte consistenţa programelor realizate, deci întreţinerea lor va fi mai puţin 
í costisitoare; 2 ED $ 
- -scade complexitatea programelor: trebuie realizate numai componentele specifice 
domeniului de utilizare. : 
Cu toate aceste avantaje evidente si a altora neenunţate, există numeroase impedimente, . 
obiective sad subiective, care complică aplicarea reutilizării pe scară largă. Astfel: 


-- este mai simplă, realizarea unei componente nereutilizabile decât realizarea unei , 
: ` componente reutilizabile; Ge ; ; 
- experienţa și cunoştinţele acumulate de programatori nu sunt suficiente pentru ca 


D ` a N 


aceştia sá.fie capabili sá producă componente reutilizabile: este nevoie d 
simi special, de. capacitate de abstractizare şi generalizare; ps 

avantajele reutilizării nu apar imediat; pentru promovarea reutilizării este nevoie de 
investiţii mai mari (decât în cazul nepromovării ei), deci este nevoie de timp mai 
îndelungat pentru amortizarea cheltuielilor suplimentare; 

o politică de reutilizare a softului implică schimbarea stilului de muncă, atât în 

organizarea procesului de dezvoltare, cât şi în programare; 

- apare problema organizării depozitelor de componente reutilizabile, văzute drept 
colecţii ierarhizate de module; există deja astfel de depozite, numite în engleză 
frameworks (colecţii de clase destinate realizării de interfeţe utilizator: Turbo 
Vision în Turbo Pascal) şi tool-kits (mulţime de instrumente, constituite pe una 
Sau mai multe frameworks, ce permit utilizatorului să interacţioneze cu mediul 
de lucru pentru a configura sau construi noi produse program). . 


În [Tra88] Tracz formuleăză două reguli (gen "legile lui Murphy”) pentru reutilizare. 
Acestea sunt: 


1. Înainte de a dezvolta soft reutilizabil, trebuie să-l foloseşti de cel puţin 3 ori; (ai nevoie 
de cunoaşterea domeniului si de experienţă înainte de a face ceva reutilizabil); 
n 2. Înainte de a te bucura de beneficiile. reutilizării unei componente, trebuie să o 
refolosesti de cel puţin 3 ori; (costul softului proiectat în ideea reutilizării este 

cu 30% până la 200% mai mare decît costul softului "clasic"). : 
Din discuţia anterioară se pot enunja câteva direcţii în care trebuie dirijate preocupările 
viitoare (metodologice, organizatorice, de perfecţionare a limbajelor şi mediilor de programare), 
în scopul folosirii pe scară largă a reutilizării [Civ93]:.  £ — - ; 
- componentele reutilizabile trebuiesc depozitate în biblioteci, organizate ierarhic şi 
m bazate pe abstractizarea datelor; codul sursá nu este cea mai potrivitá alegere; 
"Y - limbajul de programare folosit in implementare trebuie să posede. facilități de 

X modularizare (cel puțin); ' GC 
- trebuie acordată: o atenţie specială formării si perfecționării programatorilor în 
utilizarea abstractizării datelor și reutilizarea softului; db 
- Ja nivelul unei organizaţii soft, reutilizarea trebuie gândită ca politică generală, în ideea 

recuperării; costurilor suplimentare pe care le implică-promovarea ei; 
E =- metodologia de gestionare a'depozitelor de componente reutilizabile este încă săracă; 
d trebuie dezvoltate noi metodologii şi trebuie create instrumente automate 
, (browsere) de gestionare; de asemenea, problema partajării acestor depozite 
z - între diferiți programatori/echipe este departe de a fi rezolvată. ` 


23. PROGRAMAREA DIRIJATĂ DE OPERATII Sa 
Metodele de construire a produselor program se pot împărți în trei categorii, fiind numite 
metode de: deve Ur EE ; 7 pee : 
- programare dirijată de operaţii, LU 
- programare dirijatá de date (bazatá pe obiecte); 

- ^4 - programare orientată pe obiecte. USER: A : 
În această secţiune vom face o succintă trecere in revistă a primei categorii de metode, urmând 
ca să discutăm metodele bazate sau orientate pe obiecte în capitolele următoare. , 

y . " 


1. Metodele de proiectare "dirijată de operaţii” au fost discutate în capitolul I: programarea 


61 


structurată, top-down, rafinarea succesivă, Ele sunt considerate metode "clasice" 
încercă de ordonare 


a acestora este ceca ce numim "descompunerea funcţională”. 


i , fiind primele 
a procesului de dezvoltare a produselor program. Caracteristica comună 


.. Reamintim că descompunerea funcţională a unei probleme P înseamnă găsirea unui 
număr de n componente (subprobleme) Pub, din cu următoarele proprietăţi: 
- Becare problemă P, (1«isn) se poate rezolva independent, putând fi descompusă la 
ráàudulei ` f 
- fiecare problemă P (1 sisn) este mai simplă decât P; 
- soluția problemei P se obţine din reuniunea soluţiilor problemelor P; (1 sin); 
- subproblemele P (1 sin) sunt deduse din specificarea problemei P; 
- pentru o problemă P, (1«isn) procesul de descompunere se opreşte când ea este 
suficient de simplă și se poate implementa direct. 


Descompunerea se numeşte funcţională deoarece ea are ca obiect funcţiile problemei P. 
Etapele descompunerii sunt: SSC 2 ; 
4 1. Identificarea funcţiilor (compohentelor, subproblemelor) care trebuiesc realizate 
(rezolvate); - < ~ 4 ; 
2. Proiectarea structurilor de date necesare pentru întreaga problemă; 
` S. Stabilirea şi proiectarea operaţiilor necesare în strânsă legătură cu structurile de date 
alese. ta i 


Ideea descompunerii funcţionale nu este nouă. În activitatea sa de zi cu zi, omul este 
obişnuit să rezolve o problemă complicată prin înlocuirea ei cu mai multe probleme mai simple. 
Încă din primele ore de matematică, elevii sunt deprinşi'să reducă o problemă nouă (aparent sau 


! efectiv), la una sau: mai multe probleme cunoscute, fiecare de complexitate mai mică decât cea 


inițială. Descompunerea funcţională, ca metodă de proiectare a programelor, este caracterizată 


„de: : ` 


- medetalierea (ascunderea) algoritmilor: se precizează funcțiile. subproblemelor 
3 > (componentelor) si-nu algoritmii folosiți (se specifică CE trebuie să rezolve 
subproblema P; şi nu CUM se face rezolvarea); 
- detalierea! structurilor de date folosite, care trebuie să fie accesibile pentru toate 
subproblemele. i 


Metodele de proiectare dirijată de operaţii au apărut in anii 60-70, fiind influențate de 
limbajele de programare cunoscute în perioada respectivă. De altfel, limbajele recomandate 
pentru implementare aparţin primelor două generaţii: SES $ 

1. cele care opercázá humai cu tipuri predefinite (FORTRAN, ALGOL, BASIC, COBOL), în 
general. puţin adecvate pentru programarea de aplicații mari; ; SS 
2. limbajele ce posedă, pe lângă tipurile predefinite, și mecanisme de construire a tipurilor 
utilizator (ALGOLO6S, Pascal, C); aceste limbaje permit. definirea de structuri de date coniple- 
xe, dar nu permit absfractizarea datelor: constructorii de tipuri nu servesc şi la definirea - de 
operaţii noi pe tipurile utilizator. ` apti ac tM 


„Aşa cum am arătat anterior, metodele de proiectare dirijată de operati au apărut din 
necesitatea organizării eficiente a procesului de dezvoltare a produselor program, ca o consecință 
firească a creşterii complexităţii programelor ce trebuiau realizate. În anii 60 au apărut deja 
produse soft de complexitate mare (între Acestea putem enumeră in special componente ve 
sistemelor de operare, dar si aplicaţii de gestiune a volumelor mari de date). Principal zi 
dezavantaje ale acestor metode de proiectare dirijată de operaţii (PDO) s-au revelat în faza e 

"intreţinere a respectivelor produse soft, Între aceste dezavantaje menţionăm:; 


í 


pi SA A | X 


L PDO încurajează programatorul să se concentreze asupra fubcţiilor programului 
realizat $1 nu asupra datelor de prelucrat. Această atenţie acordată funcțiilor, în 
detrimentul datelor, are efecte negative în ceea ce priveşte securitatea datelor: 
o anume componentă a SD poate fi modificată accidental în orice subprogram 
SP; deci şi acolo unde n-ar fi voie să se facă modificarea. În plus, s-a constatat 
că funcțiile programului sunt mai volatile (se modifică mai repede) decât datele. 

2. Structurile de date folosite nu sunt discutate la nivelul abstráct, ci în. termenii 
limbajului de programare folosit (înregistrări, tablouri s.a.m.d); prin urmare; 

SÉ proiectele logice obţinute sunt rigide, bazându-se pe notații fixate, iar orice 
. modificare a structurilor de date va atrage modificarea algoritmilor aferen(i; 

3. PDO creează arhitecturi centralizate si rigide, formate dintr-un modul principal și mai 
„multe module apelate din modulul principal; această structură arborescentă a 
„modulelor are efecte negative când aceeaşi structură de date este necesar să fie 

“vizibilă în module aflate pe ramuri distincte; de obicei în această situaţie 
„respectiva structură de date este ataşată modulului rădăcină, fapt tare face ca 
. ea să fie accesibilă şi modulelor care nu an nevoie de ea, neprotejând-o 
^. corespunzător la modificări involuntare, De asemenea, comunicarea între 
_ module este greoaie, ea putându-se face doar urmând ramurile arborelui; deşi 
numárül de legături între: module este mic, debitul informaţiei schimbate este 
4 „mare sko mare partea acesteia nu este prelucrată, ci doar transmisă spre alte 
pe -. “module (aflate în aval sau amonte de modulul în cauză); . ; z 
„4 PDO descurajează reutilizarea, modulele proiectate fiind dedicate problemei de 
„ui rezolvati acest lucru este evident din aserțiunea: modulul corespunde funcției; f. 
5. Întreţinerea unei aplicaţii realizată prin PDO este greoaie şi foarte costisitoare, orice 
^, + modificare a specificaţiilor (structurilor. de date) având efecte în toate modulele” 
|”, în care suntvizibile respectivele structuri, i , 
6 În concluzie, PDO oferă produse program slab compatibile între ele si cu, - 
C ia St x -extensibilitate scăzută. i $e a = ZA ies m Mr c Kt AE IA 


CAPITOLUL 3 


TIPURI DE DATE ŞI STRUCTURI DE DATE 


3.1. NOȚIUNI INTRODUCTIVE 


În această secțiune vom defini câteva no 
prezentul text. În paragraful 3.1.1: vor fi discu 
Paragraful 3.1.2 definește tipurile si. structurile 
nivelele de abstractizare a datelor. 
nivelele virtual si fizic. 


[iuni şi concepte fundamentale, folosite în 
taţi termenii de dată, structură, valoare. 
de date, iar în paragraful 3.1.3 se discută 
Ultimul paragraf prezintă tipurile de date primitive, la 


3.1.1. Noţiuni şi concepte preliminare z 

, Se spune adesea că sistemele de calcul prelucrează informaţii. În realitate, 
calculatoarele prelucrează date, ele numindu:se complet sisteme de prelucrare a datelor, (data 
processing systems în limba engleză). O primă accepţiune a termenului de informaţie 
desemnează incertitudinea înlăturată în urma. aflării rezultatului unui experiment. sau 
răspunsului la o anumită întrebare. Astfel, la întrebarea: "Ce știi despre Ionescu?" adresată 
unei persoane care îl cunoaște, putem obţine, de exemplu, următoarele: "Ionescu are vársta 
25 (ani), este căsătorit si locuieşte in Cluj-Napoca, pe strada Unirii nr. 12". Am obținut un 
răspuns care conţine informaţii despre: vârstă, stare civilă si domiciliu. Fiecare din aceste 
caracteristici poate lua o valoare dintr-o mulțime de valori posibile. Informaţia constă deci 
din două elemente: denumirea caracteristicii şi valoarea ci. 


Termenul de dată este folosit pentru a reprezenta valoarea unei informaţii 
(cantitativă sau calitativă) utilizată ca element de raționament, discuţie sau calcul. Spre 
exemplu, ^. 

(nume, Ionescu’), 
(vârsta, 25), * 


În rezolvarea cu calculatorul a unei probleme, denumirile caracteristicile se 
subînțeleg, în calculator introducându-se numai datele corespunzătoare. Astăzi există si 
sisteme de prelucrare a info 


poate scrie, sau poate fi precizat prin reprezentarea sa în 


Din punctul de vedere al complexităţii lor, datele se pot împărți în date atomice 


` A 65 


* 


Organe) unei substanţe, 


. 25 şi "căsătorit 


(simple), când valoarea lor nu nè şi 

Sim] se poate descompune şi date structurate (grupate), cán 

Kaa lor este un n-uplu (n 22) format din n valori. Structura defineşte idum S 
punere) sau relaţiile ce st pot stabili între elementele (considerate ca particule, părţi sau 

corp sau sistem. Pentru exemplele noastre: 


sunt date atomice, iar 
Cluj-Napoca”, "Unirii, 12) ` 


este o dată structurată, elementele ei fiind localitatea, strada și numárul.' Elementele 


componente ale unei date grupate sunt la rândul lor date simple sau grupate și se numesc , 
câmpuri. ` 


N í 
a Is 
H ` 


3.1.2. Definiţii şi clasificări 


Esenţa noţiunii de tip rezidă în tentativa de grupare a unor obiecte după caracteristici 
comune, în clase sau specii. Conceptual, un tip de date (TD) este văzut ca o mulțime de valori 
posibile (numite si realizări ale tipului), care formează domeniul D al acestuia si o mulțime 
O de operaţii, funcţii şi relaţii care operează cu aceste valori şi definesc comportamentul TD. 
În sens matematic un tip este un sistem relațional, iar operaţiile, funcţiile sau relaţiile ocO 
pot fi considerate ca funcţii de una din formele: ; 


; 0:D* -^D*, o:E *D*, o:D" -E, p,q21, : (1) 
unde E este domeniul unui alt tip de date. LM S E 


Reamintim că o relaţie n-ará p cD xD yx. xD, poate fi reprezentată ca o funcţie de 
n variabile: ERRAT E D penu E E 

us Utm PUD XD AD Bj, 
unde B, = (FALSETRUE) şi. e nn 


f 


fld,dz-„d,) = TRUE œ (dd5-,d)) € p- 


Desi matematic elementele din O sunt funcţii, în literatura de specialitate ele sunt 
numite şi operaţii sau servicii, denumiri pe care le vom folosi şi noi în continuare. | ` 


în cazul în care domeniul D este format din date simple, avem un tip de date simplu 
(atomic) TDA, iar când. valorile din D sunt date structurate, operam cu un tip de dale 
structurat sáu cu o structură de date TDS. Un obiect décompozabil are gae Ss 
elemente componente, care pot fi date simple sau structurate şi structură, ultimul atribu 


definindregulile ce leagă sau pun împreună elementele obiectului. În acest caz, operațiile TDS 


. pot acţiona pe tot domeniul.D sau pe elementele componente. Domeniul D al TDS cu p 


'elemente poate fi vázut ca un produs scalar al domeniilor elementelor componente: 


t d 


D= DXDax.. XD piP 22, E S (2) 


x iai operaţiile vor fi de forma (1), cu precizarea cá in locul întregului domeniu D al TDS poate 


it ori yj il œ 1sisp. 
A 'subprodus scalar al domeniilor elementelor componente D, : 
d SEET este dotat cu o relație de ordine (parțială sau totală) şi 


pentru fiecare element este definit precedentul şi următorul său, atunci TD se numeşte 
"ordinal — ` on Adr HR RC ES REI : 


H 


3.1.3. Nivele de abstractizare a tipurilor de date 


„Noţiunea de tip de date este discutată aici din punctul de vedere al programării. Î 
fond, existà două entităţi care cooperează: utilizatorul uman, ce posedi inteligenta d fose i: 
un limbaj specific speciei umane şi magina fizică (calculatorul), care execută in ui S 
format din instrucțiuni pe care cl le înțelege. Intermediarul între aceste entităţi este viai 
virtuală, necesară unei comunicări cát mai lesnicioase între cle, cu alte cuvinte un limbaj de 
programaro, 


i „Se pot distinge trei nivele de abstractizare ale unui TD simplu sau structurat: abstract, 
virtual gi fizic. Ordinea de enumerare a acestor nivele pleacă de la utilizatorul uman si are ca 
destinaţie mașina fizică pe care se lucrează, calculatorul. 


Plecând de la raționamentul uman, primul nivel este cel abstract, concretizat în ceea 
co numim tip abstract de date TAD. Abstractizarea are rolul de a pune accent pe proprietăţile 
esenţiale ale TD (vizând atât domeniul, cát şi operaţiile), neglijând detaliile de reprezentare 
şi algoritmii necesari pentru realizarea concretă a operaţiilor. Altfel spus, TAD pune accent 
pe semantica TD, în mod esenţial pe comportamentul acestuia, precizând CE trebuie să facă 
fiecare operaţie și NU CUM acţionează aceasta. Abstractizarea poate fi văzută şi ca o 
modalitate de ordonare a gândirii umane. Concepereaunui TAD înseamnă: identificarea TAD 
(în termenii raţionamentului uman), stabilirea unui nume (care să sintetizeze proprietăţile - 
sale), precizarea domeniului şi a operaţiilor. Definirea domeniului înseamnă enumerarea 
proprietăţilor pe care trebuie să le îndeplinească valorile TAD, iar definirea fiecărei operaţii 
o€D, o:E-F itiseamná: stabilirea condiţiilor de utilizare corectă a ei, stabilirea domeniului 
E şi a codomeniului F, precum și precizarea rezultatului ei. 

Nivelul abstract este cel mai apropiat de definiţia datei, văzută ca element purtător 
de informaţie. La acest nivel, detaliile de reprezentare a valorilor posibile ale ei (domeniul 
TD) nu sunt precizate, esenţiale fiind operaţiile, adică comportamentul, funcţionalitatea datei, 
posibilităţile de valorificare a informaţiei conținută în dată. Definirea TAD poartă numele de 
specificare. 

“Nivelul intermediar de âbstractizare este cel virtual, în care se execută următoarele 
acțiuni: e e a i 
- se alege un limbaj de programare LP (masina virtualá); 
- se defineşte reprezentarea TAD în termenii LP; ` E MS 
- se proiecteazá algoritmii necesari pentru operaţii cu ajutorul reprezentării alese; 
- se scriu operaţiile TAD ca subprograme in LP. ` : 
Maşina virtuală există numai. ca ó combinaţie între compilatorul, (sau interpretorul) LP, 
sistemul de operare şi arhitectura hard a calculatorului gazdă. LP posedă TD proprii şi/sau 
mecanisme de tipizare, precum şi un set de instrucţiuni, cu ajutorul cărora se pot exprima 
reprezentarea şi operaţiile TD concepute la nivelul abstract. La nivelul virtual putem vorbi de 
o concretizare a TAD, obținându-se un tip virtual de date TVD. Trecerea de la TAD la TVD 
a fost numitá implementare sau codificare in primele douá capitole. 


Ultimul nivel de abstractizare este cel fizic, in care componentele TAD sunt 

, exprimate folosind resursele fizice ale calculatorului (memorie fi instrucțiuni cablat): ca 

rezultat al procesului de traducere a TVD. Maşina fizică poate fi considerată şi ea a m , 

în care domeniul ar fi memoria, iar operaţiile ar fi instrucţiunile cablate. Din pua S Ze ere 

fizic, memoria poate fi vázutá ca un vector de octeți (octetul fiind unitatea a sab à), x 
unt singurele operaţii pe care maşina ştie să le execute, ele torman 


instruciunile cablate îi model de TD îl vom numi tip fizic de date TFD. Trecerea de la TVD 


i ină. Aces t i 1 à 
DET prin traducerea programului, cu ajutorul unui translator (compilator, 
asamblor sau interpretor) şi eventual a unui editor de legături. 

| ei nivele de abstractizare ale unui TD şi transformările de trecere 


` Rezumând, cele tr 
Rezumând, 9 


sunt prezentate în figura 3.1.1. 


OM Á 
f MAŞINA 

—— DN TU ——— —— TER 3 
specificare implementare ^ . traducere 


Figüra 3.1.1. Nivele de abstractizare ale unui tip de date 


„N Fiecărui nivel de abstractizare îi corespunde un limbaj în care trebuiesc precizate 
componentele TD, adică domeniul și operaţiile, conform tabelülui 3.1.1. 


| Limbajul de specificare à TAD poate fi formal sau informal. Limbajul formal este 
riguros, exact, dar greu de jeles de iiespecialişti (făcând apellà notații matematice), pe când 
limbajul informal este mult mai apropiat de exprimarea umană, chiar dacă el suferă în rigoare 
şi exactitate. Specificarea formală a TAD utilizează în esență mecanisme algebrice (algebre 
universale, algebre multisortate, Y-algebre), reprezentând astăzi o direcţie importantă de 
cercetare în informatica teoretică. |, — ZA! 

| Limbajul dé programare; văzut ca mijloc de exprimare la nivelul virtual de 
abstractizare; poate fi mai apropiat de mașina fizică (limbaj de asamblare) sau de ütilizatorul 
umáan (limbaj de nivel înalt). Îi ambele ipostaze, folosirea lui este condiţionată de existenţa - 


üiiui translator capabil să traduca TVD într-un program executabil pe másina fizică. 


“Tabelul 3.1.1. Nivele de abstractizare si limbaje ` 
„Traducerea TVD inseamnà exprimarea lui (ca reprezentate și operaţii) în limbaj 
maşină. Ca programe; TVD şi TED sunt semantic echivâlenie, deosebirea dintre ele constând . 
doar în mijloacele de exprimare, adică în limbajul folosit. 
. . Niél . Wiel virtual „Nivel fake 
| abstract |  . (Turbo Pascal) - 1 (procesor 80x86) — 
S | Record | implementarea 
See Wiese —. | TD Record pe ` 
Sirada:Siring[10]; ` ` IBM-PC 
, Numárinteger | 
End ; | 
Temperatüri implementarea 
mags. Mm az TD Array pe + 
medii lünare dBM-PC 
Figura 3.1.2. Tipuri de date şi nivele de abstractizare 
fir Nivelele de abstraetizare şi clasele de tipuri de date sunt ortogoiiale, adică pot fi uale 
în considerare independent: in figura 3.1.2. sunt prezeitateë câteva exemple de date gin 
d ' categorii diferite, pe cele trei nivele de abătrăctizare; 
E ANE TH Eh 


np 
D 


ÎN n N a 


3. 14. Tipuri de dale primitive 


„Atât lă nivel fizic, cât şi Ja Dud virtual, există TD predelinite sau primitive. Aceste 
TD (in de natura intima a masii fizice sau virtuale, tà sensul că atât teprezentarea lor, cât 
şi operajile suat proprii respectivelor nivele de abstractizare. Astfel, pentru nivelul fizic 
clasele de TD suit stabilite de arhiteetüra procesorului, ce dictează reprezentarea fizică a 
valorilor ăcestoră, iar operaţiile sunt de fapt instrucțiunile maşină cablate: La nivel virtual, 
pentru un limbaj de programare partieular, TD sunt cele predefinite în limbajul respectiv; 
existând, încă din faza de specificare à limbajului, precizări privind domeniul și operaţiile 
asociate acestora. În tabelul 3.1.2. sunt prezentate câteva asemenea tipiiri pentru procesorul 
80286 (maşina fizică) şi pentru limbajul Pascal (văzul ca magina virtuală). În momentul în 
caré se realizeazà un program traducător pentru maşina Virtuală, implementat pe o maşiñä 
fizică concretă, TVD vor fi specilicate în termenii TED ale respectivei main fizice. Acest 
luerü îiseanină că reprezentarea TVD (TD predefinite ale EP) va fi exprimată cu ajutorul TD 
predefinite ale maşinii fizice, iar operaţiile TVD (instrucţiunile LP) se vor traduce în 
instrüepiuni maşină; adică în operaţii ale TD Paie, 

A. jnfune(ie de apropierea de masina fizică, limbajele de programare se împart în două 
mari categorii: limbaje de asamblare şi limbaje de nivel înalt: Pentru un limbaj de asamblare 
LA, TVD sunt foarte apropiate de TED, deosebirea constánd doar în aceea că se folosese 


| Procesor 286 —— ` 


| bit | 
| Byte char 
e | &ddréss integer 
„| integér E el 
| eM y-coded-decisal (BED) | pointer 
E , 


 Tfabelui 3.1.2. TD predefinite la nivel fizie şi Virtual 


innemonice (care sunt mai sugestive) în locul eodurilor de operaţii din limbajul maşina; 
păstrându-se în schimb reprezentarea TFD pentru TVD. De aiei result că LA este dedicat 
ünei masini Baler concrete. Adevaratele maşini virtuale sunt limbajele de programare de nivel 
înalt PNI, care sunt specificate EE de maşina ‘fizică: La specificarea acestor 
limbaje; reprezentarea si operaţiile TV predefinite se discută numai la nivelul abstract: la. 
momentul în care se implementează ua translator al LPNT peatru © maşină hoc dată, se ` 
concretizează aceste abstraetizari, folosindu-se Be LA al maşinii; fie ün limbaj dedicat 
(limbajul C de exemplu). Dacă o instrucțiune din ŁA se traduce într:6 instrucțiune mașină; 
în general pentti L ENT o instrucțiune se Và traduce în mai mülte instrucțiuni mașina. Desigur; 
anumite aspecte de implementare nu asiţiură o portabilitate 100% a programelor sürsä serise 
într-un LPNÍ de pe © maşină pe alta; însă adaptările necesare süni; in general, minime: 
Nivelul de portabilitate depinde de, gradul de precizie al speciliearii ie : ŁPNÌ si de 
masura îi care aceste specificații sunt respectate de eatre echipa de implementare a 
programului traducător: | 

Geier LPNÎ un loc aparte fl ocupa LP puleraieipizate. Această proprietate taseamna 
în weg tipul ldentihcatorior fa pelt inlr-um program este a A moment 
égimpilarii şi că valoarea uneiwariabile trebuie să De compatibilà eu tipul acesteia: ` 


3.2. TIPURI ABSTRACTE DE DATE 


3.2.1. Specificarea tipurilor abstracte de date 


i Aşă cum am arătat in 3.1.3, TAD se precizează cy ajutorul unui așa-numit limbaj de 
specificare, formal sau informal. În cele ce urmează, vom folosi un limbaj de specificare 
informal, cu ajutorul căruia vom defini scheme de specificare pentru TD simple gi pentru TD 
structurate, În esenţă, o schemă de specificare a TAD conţine două părţi: specificarea 
domeniului TD şi specificarea operaţiilor. În cazul TD structurate, specificarea domeniului 
TD înseamnă: specificarea elementelor (descrierea elementelor componente), specificarea 
structurii (adică a relaţiei sau legăturii dintre elemente) şi specificarea propriu-zisă a 
domeniului (descrierea mulţimii valorilor posibile). Specificarea unei operaţii se realizează 
în manieră procedurală, operaţiei atagándu-i-se un nume, o listă de parametri, ea furnizând 
un rezultat. De asemenea, pentru fiecare operaţie trebuiesc precizate precondiţia si 
postcondiţia. Precondiţia este o aserţiune (afirmaţie) care precizează în ce condiții operaţia 
are sens şi ea trebuie verificată pentru ca operaţia să se execute corect, iar postcondi(ía 
exprimă. legăturile dintre. rezultatele obţinute în urma executării operaţiei si operanzi in 
ipoteza verificării precondiţiei. Este important de precizat că postcondiţia specifică numai CE 
rezultate se obţin, fără a intra în detalii privind CUM se obţin acestea. În figura 32.1 
prezentăm schemele de specificare pentru TAD simplu, TAD structurat şi pentru o operaţie. 


1 


Pentru exemplificare, vom specifica cáteva TAD simple: Zile, Natural si Sutime $i 
TAD structurat Monede. . - 3 ; SSRS : 


H 


Specificarea 324. Tipul abstract. simplu Zile 


SAP = (luni,marţi,miercuri,joi,vineri,sâmbătă, duminică). 


| SER Domeniu: mulțimea valorilor posibile este: 
Operații: 


leri(z:Zile):Zile x. aer De {Stabileşte ziua precedentă 
, ` È EE 2 SE AUR a zilei z) 
n Pre: zeSAP. ` EE ` 
` Post: Ieri(z) este ziua precedentă a zilei z. ^ 
i à : 


` Máine(z:Zilc):Zi E s wes x Stabileşte ziua ce urmează 
Mame (zzi) Zile A: SCH SE m ME See 

pre. ZESAR a a EE ^ 
Post: Máine(z) este ziua următoare a zilei 5 : : 
S  Liber&(z-Zile)-Boolean Qs e Ñ ` - {zeste zi nelucrătoare ?) 

l Pre: EE Ee CZ 
Post: Dacă z estezi nelucrătoare. ` pce oT 
`= wtuncdLiberá(z) este True >... À 
^ — altfel Liberá(z) este False. | 5 


Seit 


; Su Schema de specificare a TAD simplu ` ` 


_- Domeniu: descrierea mulțimii valorilor posibile ` 


Operații: specificarea fiecărei operaţii, vezi c) — 


b) Schema de specificare a TAD structurat 


Elemente: descrierea elementelor componente 


Structură: descrierea relaţiilor sau legăturilor între 
- elemente 


Domeniu: descrierea mulţimii valorilor posibile 


Operații: specificarea fiecărei operaţii, vezi c) 


C) Schema de specificare a unei operaţii 
. Nume: numele operaţiei E mai. sugestiv) 


Listă de parametri: specificarea parametrilor, ca . 
perechi (identificator, TD) 


Rezultat: (când operația are sensul unei funcții Rascal) 
TD al rezultatului întors 


Pre: UE (eventuale condiţii impuse poramermier 
de intrare) : 


Post: postcondifia (RUE legáturilor dëser 
rezultatele obținute si parametrii de mirare) 


Figura 32. 1. Scheme de eM Sens 


Scrie(z:Zile) : AEN (serie valoarea lui z la dispozitivul 


standard de ieşire] 
Pre: zeSAP. 
Post: Se va afişa ziua z ca şir de caractere. zi 
Citeşte(var zZile) ^ . - -- (Citeşte valores luizdela - 
DUE . dispozitivul s standard de intrare] 
Past: “rezultatul: z se va cii c şir SE caractere ce reprezintă o valoare din domeniul 
„SAR. ER | i 


M A 
Y 


Specificărea 322. Tipul abstract abia Natural + 


Domenii mulţimea, valoălor posibile es este multiméa N Na numerelor naturale. 


„Operații: SC = d ee : Xe > FE T SS [3^4 ` 
EE EE ur wi “(al 2122). 

Pre: n1 si n2 sunt din N. CAT : 

Post: Dacánl > n2 ` ES 

e atunci Mare Cl) va fi True S EOM 
ME -altfel Maier ta E va ale PI A 
Ega Kan: Natural); Boolean NI o i 
“Pre: ni şi n2 sunt dia N. `- d Id 

Post: Dacánl —n2  . 


[n1 = 222] 


ELSE E E SE m 


atunci Egal(n1,n2) va fi T 
aie EN fi False. 


Adună(81,n2:Natural; var a:Natural) 


Pre: ni i na sunt da N {calculează suma lui n1 și n2) 
: Post: n — ni + ; 


Beade(n1,82; oh var n:Natural 


) 
Pre: nisi n2 = dia N i 
utr $ ihi $ MaiMare(ni, p2). 


{scade n2 din n1} 


Ori(ni,n2:Natural; var Nur) 


Pre: E a aia N 
Post: n = nl 


Cát(n1,n2:Natural; var AED SH i Se E 
Pre ni sind sunt dia Ni gett t xc s ung lui n1 la n2] 
Post: n = nici Bus a câtului SÄI n2. 


, {calculează produsul lui n1 si n2} 


H 


Rest(nd a? Natural Var n: AM 


DM TIN à 
j Pre; Peara" Í m SE ui n1 la n2] 


Post: n = n1 - Cât(n1,n2) * n2 


ipecificarea 3.2.3. Ted abstract simplu Sutime 
` Domeniu: m uian valorilor de este milies numerelor naturale cuprinse 
iis 8 ; ; 


între Pa notată papa 
„Operații SE : : m m E. 
MaiMare(shs2:Sulime):Booleaa ` < EES 
SUE ii sl F cro : 


Post: Dacă s1 > s2 
atunci Ma Marels L2) + va fi True 
< altfel MaiMare(s1,52) va fi False: 


Egli Bine) Boots Don de e docs M eg) 
: eut i aa SE 
ost: Dacă s De e 
. . atunci Eun va fi True : - 
altfel Egal(st,s2) va fi Faise: 


E Sutime) 
 Aduni(s1,52:8utimé; var naturali var sut ` v: m drums luda oi 
Pre: 51 și 82 sunt din DS: 


Post: s va conține partea fraețienară a sumei dintre s1 și 82 iar n va conține partea ` 
întreagă a acesteia (transport 


 Seade(sls2:Sutime; var s:Sutime) ` ` EH [sedes din s 


* 


us 


Pré: si şi 82 sunt din DR si 


Poor 1,82) 8 CR al 
bet (8 i au Egal(s1,53). 


Y 


Speeificarea 3.3.4; Tipul abstract strüetürat Monede 
Elemente: Elementele componente sunt partea întreagă, respeetiv partea fraepionará 

à unei sume monetare: 
sc Se notează eu Lei pariea întreagă a sumei; respeetiv eu Bani re hens 


haetenar a acesteia; există 6 earesponden|à unü-la-umu între fiecare 
identificator şi elementul eoripeRent corespunzător: 


Domeniu: Valoarea părții întregi a sumei, Lei, este un număr natural, iar cea a părții 
A fracjionare; Bani, este în intervalul natural 0.90. Domeniul tipului 

Monede; DM este văzut ea produsul cartezian al acestor două domenii ale 
elementelor componente: - 

Operații: - : Së 

BanilnMonedefa: Sutime; Var Fi Ge 
: - (transformă suma n exprimată în Bani în Lei și Bani) 
re: n 
Post: i site valoarea lùi a exprimată în Lei şi Baai: 


LeiliMonede(seNatural var r:Menede) ! 
[transforma suma ñ exprimată în Lei în Lei si Bani) 


Pře: a EN 

Posti £ este valoarea lui a exprimată în Lei şi Bani. ; : 
LeibinMonede(s Monede): Natural o0 00 partea întreagă a sumei} | 

kon DEM este valoarea campului iei l 


; 1 iSutime 
BinibiaMonede(s Monede): Sutim „partea fracionară a sumei) x 


€ DM 
Pr D este valoarea ea cpu Bani- ^ 


: MonedelnReals Monede): Real | dulce dan Du 

^ Prei s eBM: SS | à 
SEM Real 8) se SEIN astfel: 

zu e Lei * d Bani / 100: A 


i MM us "EN, numàrului real r eonvertità la hia Monede ix 
Pre 


Posti i 5 e SM are i pnentele; RU 
tea tütreaga à ORAS PS ES - 
Er Bani ag Zä primele geu sécimale dia pansa fracționară à li 


MaiMare(s1,s2:Monede Boolean | 
Pre: s1, s2 € DM. ; Mea 


Post: Dacă sl > s2 
atunci MaiMare (s1, s2) va fi True 
altfel MaiMare (s1,s2) va fi False. 


Egal(s1,s2:Monede :Boolean ; 
Pre: s1, meh: : j ; m7 
t- Post: Dacá sl = s2 
atunci Egal (s1,s2) va f True 
altfel Egal (s1,s2) va fi False. 
j 
Adună(s1,s2:Monede; var r:Monede ă si şi 
Pre: sl, s2 € DM. De Zi 
Post: r = sl + s2. 


p eri aa 

Scade(s1,s2:Monede; var r:Monede) S 155 Fecade s2 din sl 
Pre: sl, s2 € DM si MaiMare(sL2) | pde dust. 
Post: r = sl - si: 


TU 


Scrie(s:Monede) ` . i D UE UE Tere valoarea lui s la dispozitivul 
| EE $ ; standard de iesire) . 
Pre seDM. == N ean mean 
Post: se va afişa s în formatul . SS GK, 
s Ss „1999999,99 leii. put M 


Dobânda E d: Real var r: Monede). - 
feel ulcer dobânda r aferentă sumei si ratei r) - 
"Pre: s € DM si deR. s 
Post: r = dobânda la suma s calculată cu rata dobânzii d. 


23:22: Troiéctarea operatori unui UD 


CA mai E EG fază în ‘specificarea u unui i TAD este GE mulţimii 
operaţiilor. Mulțimea SES m ansamblul ei E să Sindeplineasos următoarele 
S conditi i i | 
(1) să fie completă; 
- (2) să fie minimală, AC 
-iar pentru fiecare operaţie: EE ER 
: 6) trebuie să fie ER toate preconditil. 


bs 


zi i i După, criteriul funcționalități lor, clasele de operaţii ale unui TAD sunt următoarele 


^ (d)s ie de 2 cei, 
(2) operaţii de intrare/ieșire; ` 
NAE operaţii de conversie; ` 
EO operaţii de test; X MP E 
(5) operaţii de SE SE ` 
6) oper e selectare. ` 

Vom as) inc pes urmeazá arctice ieri clase de operaţii. rengt furnizate 


E 


: Qu Ape spe uA e 


7 7 v 
; Coustructoril sila erdi prin care se eg AIS) unor yr realizări ale TAD, adi 
^ AEREA sau medina Gd ale rap: e cazul în în care gue se realizează prin uar: d 


unor date de alt tip, constructorii 
poate formula astfel: 


se numesc iniţiali. Completitudinea setului de operaţii se . 


Constructorii unui TAD trebuie să producă orice element din domeniul acestuia. 
Exemple de constructori: BaniÎn Monede, LeiÎnMonede (iniţiali), Adună, Scade, Dobândă. 


.. Operaţiile de intrare-iegire (operaţiile de I/O) permit citirea sauscrierea valorii unei 

: realizări a TAD de pe/pe suport extern. Acest lucru este necesar deoarece, cu puţine excepții, 

TAD sunt structurate şi majoritatea LP nu dispun de operaţii de I/O cu care să se poată 

|. implementa TVD asociate TAD. Operaţiile de intrare pot fi considerate și constructori. Scrie 
este o operaţie de I/O. X BO 


: Operaţiile de conversie realizează transformarea valorii instanţelor TD în valori-de 
instante ale altor TD. Operatiile MonedefnReal si Rea/ÎnMonede fac parte din această clasă. 


Operaţiile de test sunt necesare în primul rând pentru testarea precondifiilor, putând 
fi folosite chiar în specificarea TAD (vezi specificaţiile 3.1.2-3.1.4). MaiMare şi Egal sunt astfel 
de operaţii. | RRS ; : 

Operaţiile de copiere sunt necesare când nu se poate folosi instrucţiunea de atribuire 
pentru a copia valoarea unei instante de TAD într-o altă instanţă. Pentru TAD Monede, o- 
operaţie ` UR E d 


"Y - Copy(mi:Monede; var m2:Monede) ^ ` i Si (m:=mi) 
ar fi o operaţie de copiere. ` i | 
Operafiile de selectare permit (în cazul TAD structurate) operarea cu elementele 


E componente ale unei instanţe a TAD. LeiDinMonede si BaniDinMonede sunt astfel de ` 
E operaţii. SE i i ai 


> 


O altă clasificare a operaţiilor, dată de Meyer ([Mey88]) distinge 3 clase: constructori 
E (creează noi instanţe ale TAD), accesori (permit accesul la valorile anumitor componente, 
| fără a le modifica) si modificatori (modifică anumite componente ale instanţei). Legătura 
| dintre aceste două clasificări este sintetizată în tabelul 3.2.1. = `- Ser 


H 


'constructofi inițiali ^ ^ = < 


“operaţii de conversie spre TAD a 
operaţii de intrare ` ` E Es CS 
modificatori constructori (alții decât cei inițiali) _ 
accesori ` ` operaţii de test ` ` 
operat de conversie de la TAD 7 
operaţii de selectare, - 
operaţii deieşire . 


- 


d E E EC Tabelul 3.2.1. Tipuri de operaţii SS 


e 


3.2.3. Implementarea tipurilor abstracte de date 


_ Aşa cum am precizat în 3.1.3, implementarea unui TAD resupune parcurgerea 
următoarelor etape: alegerea LP, stabilirea [SEE DR la A TADR GEES Seen 
limbaj, proiectarea algoritmilor necesari pentru implementarea operaţiilor (ținând cent de 
reprezentare) şi, în sfârşit, scrierea de subprograme corespunzătoare fiecărei operaţii, folosind 
LP. În mod normal, faza de implementare mai conţine o etapá de testare, vázutà atát la 
„nivelul fiecărei operaţii, cât si al TAD în ansamblu (testarea procedurală şi testarea de 

modul). Rezultatul implementării, TVD, va fi numit în cele ce urmează modul sau pachet, în 
ideea că el este o unitate sintactică de sine stătătoare, compilabilă separat. În secțiunea 3.5. 
vom prezenta implementările TAD prezentate în specificările 3.2.1. - 3.24. SC 


3.2.4. Facilităţi de abstractizare şi modularizare în limbajele de programare 


LP moderne posedă instrumente de modularizare (clasa în Simula, modulul în 
Modula, pachetul în Ada, unit-ul in Turbo Pascal, cluster-ul în CLU), care din punctul nostru 
de vedere nu sunt altceva decât TVD: Merită să observăm că toate aceste limbaje sunt 
puternic tipizate. 

Schematic, structura unui TVD se prezintă conform schemei date în figura 34.1. 
Interfața FVD stabileşte un domeniu de vizibilitate închis. Utilizatorul unui TYD nu trebuie 
să cunoascá nici detaliile de reprezentare ale TVD, nici algoritmii folosiţi pentru 
implementarea operațiilor acestuia. Aceste informaţii sunt încapsulate (sunt puse împreună 
reprezentarea şi operaţiile) în modul. De asemenea, modulul asigură ascunderea informaţiei 
(în engleză information hiding), care înseamnă protejarea informaţiei la acces si modificare 
nepermise. În acest fel, utilizatorul are acces la reprezentarea TVD numai prin intermediul ` 
operaţiilor specificate. Această cerință conservă integritatea reprezentării, altfel spus dă o 
siguranță sporită în utilizarea respectivelor structuri de date. S 


Modul nume 
| Interfaţă 
him S . Listá de import 
EE “Listă de export 
Reprezentare” 
ES Implementare : 
Declaraţii locale i 
` " Implementarea operaţiilor exportate 
Implementarea operaţiilor locale 
„Cod de iniţializare ` 
End modul d 


, A 


€ GE —= 


`- Figura 3.4.1, Schema de specificare a unui TVD ` 


Precizarea entităţilor definite in TD si utilizabile în alte module sau programe se 
face într-o așa-numită listă de export, care conține numele de operații, variabile, constante 
şi tipuri de date ce constituie interfața TVD cu mediul extern. În unele limbaje, exportu £ 
specifieă explicit, în altele partea de interfață reprezintă de fapt o declarație imp icită d* 
export. Pentru TD structurate, exportul poate fi obscur (când entitatea este accesibilă Ee 
în ansamblul ei) sau transparent (când este permis accesul si la elementele componente ii 

- . ntr-o manieră similară, utilizarea într-un modul a unor definiții din alte mor le e 
specifică printr-o listă de import. Această listă poate fi explicită la nivel de nume de enti lee 
(precizare făcută prin specificarea perechii nume-modul, nume-entitate) sau numai la ni e! 
de modul, caz în care este vizibilă întreaga listă de export a respectivului TVD. SE 

Aşa cum am precizat în 3.2.3, modulul este o unitate sintactică compilab e separat: 
Compilarea separată pentru LP puternic tipizate este o operațiune mat dificilă, deoarece 


D 


" 


16, i Eat qat 


compilatorului îi sunt” necesare, la momentul compilării, toate informaţiile despre 
identificatorii ce apar într-un modul. Prin urmare în cazul când într-un modul M se utilizează 
definiţii importate din alte module, sintaxa acestora trebuie să fie accesibilă compilatorului 
când acesta traduce M. Accesul este realizat tocmai prin lista de import. Compilarea separată 
înseamnă că pentru lista de export a unui niodul se va crea o bibliotecă de informaţii, care va 
fi accesibilă ori de câte ori la compilarea-altor module este necesar modulul în cauză. 
Reprezentarea TVD este, în cazulideal, accesibilă numai implementatorului, conform 
principiului ascunderii informaţiei. În practică există diverse maniere de implementare a 
acestui principiu în LP, mergând de la export transparent (toată reprezentarea este vizibilă 
în exterior) spre export obscur (sunt vizibile doar variabilele simple si cele structurate, 
ultimele fără acces la componente) şi terminând cu invizibilitatea reprezentării în afara TVD. 
Partea de definire a reprezentării TVD. poate conţine zone invizibile în exterior (declaraţii 
private) şi zone vizibile în exterior (declaraţii publice). 
Partea de implementare a TVD conţine cod sursă pentru două categorii de operații: 
operaţiile exportate ale TVD (în mod uzual operaţiile specificate ale TAD corespunzător) şi 
operaţiile locale. Acestea din urmă au rolul de a asigura o implementare mai comodă a 
primelor şi de a rezolva anumite situaţii de excepţie. Tot ca operaţii locale pot fi concepute 
cele ce operează cu reprezentarea intimă a TVD si care nu se doreşte să fie exportate. De 
asemenea, partea de implementare conţine declaraţiile de nume locale, care nu sunt vizibile 
în afara TVD. | Rc | e 
-  Ín sfârşit, codul de inifializare a TVD are menirea de a realiza anumite operaţii la 
prima utilizare a unei instante a TVD. SÉ 


“Până acum am considerat TVD ca modul, unitate sintactică. În unele limbaje de 
programare, TVD sunt legate de mecanismul de tipizare, realizándu-se astfel construirea'de 
noi tipuri de date. Aşa se pune problema şi în cazul limbajelor de programare orientate pe - 
obiecte (şi anume cele cu clase), în care o clasă de obiecte nu este altceva decât un TVD, 
căruia i se adaugă două noi proprietăţi: moştenirea și polimorfismul. De asemenea, dacă LP 
posedă facilităţi operatoriale, atunci anumite operații pot fi definite ca operatori. În sfârşit, 
facilitățile generice conferă un grad mai mare de generalitate pentru TVD. 


EI 


^. "338. Avantajele TAD 
d | 


Abordarea la nivel abstract a TD oferă câteva avantaje importante pentru activitatea de 
programare in general: ; ` E : 
„ (1) specificaţii precise; > EES 
(2) modularitate; SS 


f 


BE 4 


ascunderea informaţiei, .  -. 


is,iar semantica operaţiilor 


` "Incapsularea reprezentării şi operațiilor (punerea lor impr cună) induce ordine şi 

-onta Pentruo ânumită à de datee: uralsá se ipánu numai o operaţie, ci 
“Pentru o ânumită structură de date este natural să se conceapânu num ral 

paid de manipulare a respectivei structuri. Acest lucru, făcut independent de utilizarea 


Erat A : ă -oicctate şi asigură flexibilitate, o 
ivei structuri, permite o testare uşoară à operaţiilor proiect : n 
oH COLOR Zoe oricând a fi introdusă, dacá e nevoie. Acordarea unei atenți egale 


D 


y e kk ^ A «i | : D ^ | 3 7 


reprezentării şi operaţiilor conduce la realizar i stabi 
E nt ) a re ea * 1 a ^ f 
reutilizárii lor ín contexte adecvate. e D tu EI aT Ec 


Ascunderea informaţiei este una dintre ceri 
nu trebuie să cunoască decât m 


Abstractizarea datelor oferă simplitate. 


nțele majore ale modularizării. Modulul client 
odul de apelare a serviciilor din modulul furnizor. 
La prima vedere, termenul abstract ar avea 


înțelesul de teoretic, abscons, greu de înțeles. În cazul nostru, abstractizarea are o semnificaţie 


SE 8 Ge SEN în SSC aspectelor şi comportamentului esenţial al datelor 
3 S prin ne ijarea etalulor de reprezentare sau de implementare. Această 
poncentrare pe aspectele esenţiale oferă simplitate în proiectarea TAD de către specialist. Pe de 
altă parte, cerința de minimalitate a setului de operaţii al TAD oferă simplitate în utilizarea 
acestuia, adică o înţelegere uşoară de către utilizator a comportamentului TAD. Din aceste 
afirmaţii nu trebuie să se înțeleagă că aspectele de implementare sunt neglijate. La nivelul abstract 
acestea nu sunt luate în considerare nu pentru că ele nu sunt importante, ci pentru că aceste detalii 
vor fi discutate la vremea lor. Principiul rafinării succesive aplicat TAD înseamnă trei etape: 
abstractizare, definirea reprezentării şi implementare. A r 

Un TVD poate fi văzut ca o cutie neagră, în care operaţiile sunt butoane ce realizează 
anumite funcţii (operaţii) ale cutiei. Proiectantul (implementatorul) cutiei cunoaşte interiorul ei, 
dar utilizatorul (programatorul client) nu o poate desface pentru a vedea ce e înăuntru, ci o poate 
folosi prin apăsarea butoanelor ei. Integritatea reprezentării poate fi discutată pe două nivele; 
abstract şi virtual. La nivelul abstract, integritatea TAD este asigurată de maniera în care sunt 
concepute operaţiile sale. La nivelul virtual, dacă toate operaţiile sunt implementate corect, atunci 
nici una dintre ele nu poate afecta integritatea reprezentării. În plus, programatorul client nu va 
avea acces la reprezentarea informaţiei din interiorul modulului server. Noţiunea de integritate 
(consistenţă) a reprezentării se poate defini cu ajutorul invariantului acesteia, care este un 
predicat: 7 : D > (false,true) . SE 3 


'Spunem cá reprezentarea este consistentă dacă / are valoarea true pentru orice element din 
domeniul TAD, De exemplu, pentru TAD Monede, invariantul reprezentării este: 


I(r:Monede) — 
0 < r.Lei < MaxLongInt şi 
0 < r.Bani < 99. 


La nivelul abstract detaliile de reprezentare şi implementare a operaţiilor sunt neglijate 
intenţionat. De asemenea,+specificarea se face folosind un limbaj. specializat şi nu unul de 
programare. Prima decizie în faza de implementare este alegerea LP. Acest lucru se bazează pe 
cunoașterea TD şi a instrucțiunilor cu care acest limbaj poate opera şi are o importanţă decisivă 


în desfăşurarea implementării. Următoarea etapă importantă este stabilirea reprezentării TD, . 


i i in utili ale LP. | acelaşi TAD se pot alege 
concretizarea celei abstracte prin utilizarea TD ale LP. Pentru acelaşi 7 > 
reprezentări structural diferite, ceea ce conduce la algoritmi diferiți: Mai mult, pentru aceeaşi 
reprezentare se pot concepe mai mulți algoritmi (deci implementări diferite) pentru o aceeaşi 
operaţie. Dacă specificarea operaţiei o este corectă, modificarea codului de implementare al ei 
are un efect local, aceasta neimplicând modificări în alte module sau programe ce ipic 
Mulţi autori recomandă o abordare gradată a ultimelor două faze de implementare a unui d 
în maniera următoare, pentru o reprezentare fixată: R 

; (1) sé stabilesc algoritmii cei mai simpli pentru fiecare operaţie; 
2). se implementează operaţiile; d : x SE 
(33 i A TVD în SE (teste, de anduranţă), evidenţiindu-se operaţiile care 
- sunt mari consumatoare de timp sau de memorie; ` 
(4) se reproiectează algoritmii în cauză şi se reia ciclul de la faza (2). 


H 


is 
x 


: Procesul se încheie când în faza (3) rezultatele obţinute satisfac cerin 
când nu se obţin rezultate satisfăcătoare, se încearcă o altă reprezentare. 


` 


fele impuse. În cazul 


3.3. DATE ȘI STRUCTURI DE DATE. TERMINOLOGIE ŞI CLASIFICĂRI 


3.3.1. Elemente şi structură 


În secţiunea 3.1.1 am definit termenii de dată şi structură de date. Data, ca obiect purtător 
de informaţie, nu poate fi memorată în calculator în forma ei exterioară. Am numit reprezentare 
245 datei informaţiile referitoare la ea care se depozitează în memoria calculatorului şi care 

sintetizează aspectele esenţiale ale ei. Reprezentarea unei date structurate este definită de 
elementele componente ale ei, care sunt la rândul lor date simple sau structurate. 

În multe aplicaţii, se pune problema prelucrării unui volum: mare de date de acelaşi tip. 
Natural, elementele componente ale datei vor fi definite într-o strânsă legătură cu funcţionalitatea 
aplicaţiei. Spre exemplu, să considerăm TD persoană, care este obiectul purtător de informaţie 
în aplicaţii de personal, salarizare, asigurări sociale. În funcţie de natura aplicaţiei, elementele 
componente ale TD persoana diferă. În figura 3.3.1 am schițat posibile elemente componente ale 
acestui TD în cele trei aplicații enumerate. 


Personal Salarizare . Asigurári sociale 
- identificare - identificare ° > - identificare 
- nume, prenume ~. - nume, prenume - nume, prenume 
- loc de muncă - loc de muncă statut social 


- funcţia - funcţia studii 
studii - salar dn 
stare civilă ` - reţineri ` 
situaţie militară - număr copii 
titluri ştiinţifice 

- distincţii ' 

- limbi străine cunoscute 


Figura 3.3.1. Posibile elemente componente ale TD persoana în diferite aplicaţii - 


În aceste aplicaţii. realizările TD persoana pot fi prelucrate atât la nivel individual, cât sie global.: 
Prelucrările globale înseamnă în special obținerea unor situații statistice referitoare là toate 
' persoanele incluse în studiu (adică memorate), care sunt “parcurse secvențial, pe când cele 
individuale necesită un acces punctual la reprezentarea persoanei în cauză. Pentru aceasta, este 
nevoie ca o persoană să poată fi identificată în mod unic, pe baza valorii unui element component 
(sau a mai multor elemente). În figura 3.3.1. am numit identificare elementul component al TD 
persoana care asigură această regăsire unică. Prin urmare, presupunem în y s Să e ouă 
persoane distincte xor avea elemente de identificare distincte, deci informaţia de identificare 
i în mod unic proprietarul ei. vs EI v d ) 
EE Sie aplicaţiilor de gestiune este necesară regásirea, rapidăa e daro pe 
baza proprietăţii de unicitate a informaţiei de Sage o Man sa ee > = 
' înseamn izarea elementelor de identificare şi a njir 
componente ale TR MEETS AE tele componente vor fi împărțite în două părți: 
i cesare aplicaţiei. Prin urmare, elementele comp f i t 
c i Se sau cheia, care trebuie să de unică pent pags realiza se Ahr 
i rat) şi partea de atribute, de informație sau de P 
e EE DAL cheia este ceea ce am numit identificare, iar celelalte elemente 


EI 
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aparțin părții de date. In astfel de situaţii, vom opera cu TD TipElement, în forma: 


ee = record pd 
Cheie: TipCheie; — en » | 
Info : A Sg '  ,, (asigură identificare unică 
end: c {informațiile despre element 
vor umi e dans, ipInfo pot f ie simple sau strüctürate: Elementele componente alé lor le 


3.3.2. Clasificarea structurilor 


13:115 


j o a ilie „bi liniară .. — ebore 
2 .  - Figura333. Structuri de bază 


ip de legături 
sii ung —— P. 
ünü-la-ünü - RERS 
: arbore ünü-la-mai multe ` à 
„> || graf saü rejea | mai-multedacmai mulie 


inire elemente | 


“Tabelul 33.1. Tipuri de legătufi inire elementele unei strueturi 
` Ia afara acestor legături (cu efect de localizare à elementelor unei structuri); domeniul 


TD structurat poate fi total ordonat: 


s pina da e | o ue 
O mülfime D, înzestrată cu o relaţie R; care satisface proprietățile: 


i.aRa,pentru orlee ab . ^, 

2, Dacăa R b sib R å atüncia —b(abeD) — `  (aütisimetric) 
|^. & pacaaRbsibRcalundaRc(&bceD) ` ` y (tranzitivitate) 
se spune că este parțial ordonată în raport cu R: 


"E 


. (reflexivitate) ` 


em 


Definiţia 332; 

Dacă müljimea parțial ordonată (D;R) satisface proprietatea: 
4. Oricare ar fi a,b ED, atünci De a R b, he b Ra 

atünci (D;R) este o mul[ime total ordonatd. 


Definiția 333. | 

| O relaţie R care satisface axiomele 1-3 se numeşte relație de ordine pe D. 
Relații de ordine uzuale sunt: ` ` 

— (a) "s" pentru tipurile de date numerice (totală); 


zech 


(d) pentru un arbore; undex si y sunt noduri, relația R este o relaţie de descendență:xRy 

. dăcăyeste un deseendentdirectalluix; ` ` Se ; e 

(e) pentrü ün graf orientat, ünde x si y sunt două noduri, putem defini relaţia R astfel: 
xRy dacă există üñ are (o muchie) de lax lay. ` 

Definiţia 3:3.4. Z S EE ! 

O relație de ordine totală (notata prin " «") pe o mulțime discretă D defineşte succesorul 

(aproape) oricărui element rett, pe care-l vom nota cu suee(x); astfel: 


suce() = min[y EDx sy si y] ^— — c o (min în sensul operaţiei 2) 


Definiţia 335; ce e 
Se spiine că o răulțitie D este liniară dacă: — — 
à) pet Său — Mean a 5 
b) D conjine ün singur element sau 
(9 sunt îndeplinite condițiile: — 
„4. Deste finită si UE 
2. Există un unic element, nüimit primul; i 
3, Există un unic element; numit ultimul; ` `, 
- 4 Pentru orice element x £D, x«ultiinul există süce&); 
5. pentru orice element ze), x*primul există pred(x): 
asiattile amintite mai sus indue natural clase de operaţii pe TD respective. Astel; 
relaţia yr ipee definirea EE construiți; cu eie iät 
liniaritatea introduce operatorii de precedentă Lauer si pred) si de poziţie (ord): Implementarea 


DR 


unui 7D lini i eni i à 
bus cede si cu domeniul finit are la bazà corespondenţa biunivocă dintre domeniul 
ŞI O suomulțime a numerelor naturale. Considerând că D are n elemente, numărul natural 


i (1 sin) va determina unic al i-lea element lui i i ü 
a : ui D, el fiind poziţia sau numărul de ordine al 
elementului in D. Cu notația consacrată, dacă xeD si card(D) =n, atunci ord(x) =i, (1«i sn). 


ioa un număr natural i (1 sisn) dat, se poate determina un singur x€D pentru care 


3.3.3. Tipuri de date şi limbáje de nivel înalt 


Operaţiile unui 7D se pot clasifica după: (a) funcţionalitatea lor şi oprietăţi 

. Ot | „pot clasifica după: şi (b) proprietăţile 
domeniului TD. Variante ale primei clasificări sunt date în 3.2.2. În cele ce păzi Vo încerca 
să lămurim al doilea criteriu de clasificare. Plecând de la ideea că orice TD este realizat pentru 
a răspunde unei nevoi practice, după acest criteriu putem clasifica operaţiile în: 


(1) induse de natura elementelor TD; 
(2) induse de structura TD. 


- Natura elementelor TD conduce la definirea operaţiilor intrinseci acestuia. Exemple de 
astfel de operaţii sunt: 


- operaţiile aritmetice ( * ,-,*/, ^)la TD numerice; ` 
- operaţiile pe caractere sau şiruri de caractere la TD caracter; í 
- operaţiile logice (and, or, not) la TD logice. ` - E 5 


- Structura TD induce operaţiile relaţionale (pentru domeniile ordonate), respectiv cele de 
precedenjá (pentru structurile liniare). - e E 


Suntem acum în măsură să realizăm o clasificare generală a tipuriloride date după mai 
multe -criterii: componenţa elementelor, relațiile între elemente, specificarea în limbajele de 


programare, gradul de abstractizare. 
er. S 


Raportatá la criteriile enumerate, clasificarea arată astfel: . 
- (a) din punctul de vedere al componenţei elementelor: 
: - simple (atomice); e 
- structurale: j A 
-. - - omogene (tablou sau mulţime); 2 
i : — heterogene (iüregistrarc); `. AT xd 
——  ,(b).din punctul dc vedere al relaţiilor definite între elementele domeniului lor: - 
sje : - TD ordinale (cu operatorirelationali); ` —— : 
- TD liniare (cu operatori de precedent); ZE : ERES 
.— — - TD amorfe (posedă numai operatorii de atribuire si operatorul de egalitate); 
` (c) din punctul de vedere al specificárii lor în limbajul de programare: 
„= TD predefinite; ` spa e Da i > Get a E ATE: 
- TD definite de utilizator (se construiesc pe baza altor TD, de la.care pretu 
ze edt ^ reprezentarea, nu si operațiile); —— 
(d) din punctul de vedere al gradului de abstractizare: 
- tipuri şi structuri de date "clasice"; ` ` d ee x 
'- tipuri abstracte de date (încapsularea datelor si operaţiilor, posibilitatea preluării 
operaţiilor de la TD pe baza cărora se construiesc). es e 


H 
- 


—. Clasificarea de mai sus se poate transpune pe schema de specificarea oricărui limbaj de - 


e 


PE 


programare de nivel înalt, cu observaţia că nu nea 
O asemenea clasificare pentru limbajul Pascal Standard arată astf 
.(a) din punctul de vedere al componenței elementelor: 


părattoate elementele enumerate sunt prezente 
el: : 
- simple (atomice): ` 
char, integer, real, enumerare, subdomeniu, pointer 
- structurate: 
- omogene: array, set 
- - heterogene:.record i 
(b) din punctul de vedere al relaţiilor definite între elementele domeniului lor: 
- TD ordinale: char, integer, enumerare, subdomeniu, real 
- TD liniare: char, integer, enumerare, subdomeniu ` ` 
_ ~ TD amorfe: real, pointer, set, array, record 
(c) din punctul de vedere al specificării lor in limbajul de programare: 
- TD predefinite: j ; 
„char, integer, real, pointer : 
array şi record (ca mecanisme) 
- TD definite de utilizator (prin intermediul mecanismului type): 
enumerare, subdomeniu , 
array şi record (ca utilizare). 1 


În general, toate limbajele de programare imperative au 7D simple şi structurate 
omogene, dar cele heterogene lipsesc din FORTRAN sau BASIC, cel puţin în versiunile "clasice" 
ale lor. Unele limbaje permit definirea 7D structurate, precizând componentele unei variabile 
(COBOL, PL/I), altele posedă mecanisme de tipizare (concept mai evoluat, prezent începând cu 
ALGOL68 şi Pascal). Intre TD simple apare tipul pointer sau referință (începând cu PL/I, fără 


apariţia facilităţilor de programare modulară şi de abstractizare a datelor, când se acordă atenţie 
nu numai reprezentării, ci şi operaţiilor (Simula67, Modula, CLU, Euclid, Ada). Tipurile abstracte 
de date se pot concepe într-o. manieră ierarhică, descendenţii moștenind de la părinţi nu numai 
reprezentarea, ci şi operaţiile, cu efecte în reutilizarea codului şi deci în creşterea productivităţii 
în programare. Aşa apare programarea orientată pe obiecte (Smaltalk, C + +, Eiffel). 

Tendintele moderne în domeniul limbajelor de programare imperative includ ádáugarea 
de mecanisme proprii abstractizării datelor, programării modulare şi orientate pe obiecte. Chiar 
si limbajele "clasice" suferă puneri la zi, fie prin apariţia unor noi standarde de specificare, fie prin 
implementări care au succes de piaţă, ce extind mult standardul existent. Poate cel mai sugestiv 
exemplu este limbajul Pascal, care prin diverse implementări (Object Pascal, Quick Pascal, Turbo 
Pascal, Borland Pascal) încearcă să inglobcze concepte de ultimă oră. Rezumându-ne numai la 
Turbo Pascal, merită să amintim. introducerea compilării separate şi a modularizării (unit-ul, 
începând de la V4.0) şi adăugarea tipului de date obiect (începând de la V5.5). 


3.3.4. Implementarea structurilor abstracte 


Aşa cum am văzut, în paragrafele precedente, abstractizarea încearcă să evidenţieze 
comportamentul TD, punând acces pe semantica operaţiilor ai lăsând netratată problema 
reprezentării elementelor. Am văzut de asemenea că discutarea detaliilor de reprezentare, ca şi 
precizarea algoritmilor pentru operaţii sunt obiectul nivelului virtual de tratare a TD, când eta 
trebuie exprimate cu ajutorul unui limbaj de programare LP. Pe de o parte, Weeder D se 
va obţine utilizând TD predefinite alc LP gazdă şi mecanismele de tipizare sau abstractizare 


- existente în acest limbaj. Ținând cont de această reprezentare, vor fi proiectaţi algoritmii necesari . 


pentru implementarea operaţiilor, care apoi vor fi exprimaţi cu ajutorul instrucţiunilor LP gazdă, 


| 
} 
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Prima condiţie a unei im 
abstractă a TD. Cu această axiom 


TD-pot fi concepute mai multe i mentări i i 
1 multe implementări, semantic echivalente, dar sintactic diferi 

: ME S 1 acticdiferite. Asa cum 
am arătat în secţiunea 3.2.5, diferenţele pot viza; E ASA EU 


iplementări corecte este ca ca să respecte integral specificarea 
ă precizată, discuţia poate începe. Pentru aceeaşi specificare de 


- reprezentarea; 
- algoritmii; 
- limbajul în care se face implementarea. 


C EM există o legătură strânsă între reprezentarsa TD şi algoritmii folosiţi pentru 
nplem: peraţiilor, dar şi in acest caz, la aceeaşi reprezentare, se pot concepe algoritmi 
distincţi pentru aceeaşi operație. Pe de altă parte, LP gazdă impune restricţii atât în ceea ce 
priveşte reprezentarea, cát si algoritmii folosiţi, programatorul fiind obligat să folosească resursele 
(TD si instrucțiunile) acestuia. În concluzie, în implementare trebuie luate decizii importante 
privind concretizarea TD. Lăsând la o parte alegerea LP, ne vom concentra atenţia asupra 
reprezentării şi algoritmilor. 

n fond, eficiență unei aplicaţii poate fi văzută ca o rezultantă a eficienţei individuale a 
TD ce concură la realizarea ei (neglijând intenţionat aici performanţele calculatorului, 
programului traducatorsi LP gazdă, tocmai pentru a accentua importanța implementării). Plecám 
de la ideea că implementarea TD trebuie să satisfacă criterii de eficienţă dictate de sfera de 
utilizare a acestuia (mai generală sau strict dedicată unei probleme concrete). Aceste criterii pot 
viza in principal două resurse: memoria calculatorului şi timpul-de execuţie al operaţiilor sale. 
Criteriile amintite sunt în general antagonice (o operaţie cu timp de răspuns mic necesită 
informaţie suplimentară, deci mai multă memorie), aşa că de cele mai multe ori soluţia 
convenabilă este un compromis care le satisface pe amândouă în limite rezonabile. Există însă şi 
situaţii ce se încadrează la poli opuși. Spre exemplu, în cazul aplicaţiilor în timp real (conducerea 
unor procese cu ajutorul calculatorului, rezervări de locuri la companii aviatice, feroviare, 
hoteliere), criteriul timp de răspuns este esenţial (se consideră că sistemele de calcul pe cafe ` 
asemenea aplicaţii funcţionează posedă o memorie şi o capacitate de calcul corespunzătoare 
volumului mare de informaţii şi timpului rapid de reacţie). La celălalt pol se situează aplicaţiile 
ştiinţifice sau cele de gestiune tradiţională, în care nu criteriul timp este esenţial, ci posibilitatea 
execuţiei pe sisteme de calcul de mică anvergură, cu memorie internă şi externă redusă şi cu 
unitate centrală lentă. Mâi mult, la aceeaşi aplicaţie, volumul datelor supuse prelucrării poate să 
impună cfiterii diferite de eficienţă, care se vor reflecta în implementări: diferite. De exemplu, - 
evidenţa personalului pentru 100 de angajaţi sau pentru 100.000 de angajaţi înseamnă de fapt două 
aplicaţii diferite. Dacă în primul caz accesarea unui angájat se poate face parcurgând secvențial 
mulţimea acestora, fără mari impedimente, în al doilea accesul secvențial nu poate fi luat în 


G . "S $t H E = e 
considerare, indiferent de cát de mic ar fi timpul de acces la o înregistrare. 


Chiar şi în domeniul calculelor ştiinţifice pot apare astfel de situaţii. Este binecunoscut 


` faptul că TD numerice predefinite în LP (nivelul virtual) se bazează pe TD numerice ale maşinii 


(nivelul fizic), operaţiile aritmetice simple pe primele fiind realizate cu ajutorul procesoarelor 
aritmetice (hard). - Pentru “calculatoarele compatibile IBM-PC, arhitectură standard a 
microprocesorului nu conţine decât operatorul (unitatea de calcul) de aritmetică întreagă, 


coprocesorul matematic (care este de fapt operatorul pentru aritmetica pe numere reale) fiind 


optional. Ín'consecin(á, toate operaţiile pe numere reale sunt simulate ču ajutorul operatorului pe 


întregi, o simplă adunare reală însemnând mai multe operații aritmetice întregi (se utilizează 


nivelul fizic pentru implementarea soft a aritmeticii reale, în aşa-numitele emulatoare). Mai mult, 
în cazul în care precizia de reprezentare a numerelor întregi sau reale (cea de la nivelul fizic, 


propagată şi la nivelul virtual) nu satisface cerinţele problemei de rezolvat, se pot proiecta ca TD 


utilizator numere ín precizie (aşa-zis) infinită, care vor avea ca operații esenţiale cele aritmetice. 
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Prima condiţie a unei implementări corecte este ca va să respecte inte if 


abstractă a TD, Cu această axiomă precizată, discuția poate începe. Pen 
"POD concepute mai multe implementări, semantic echivalente, dar 
am aratat in secțiunea 3.2.5, diferenţele pot viza: 


gral specificarea 
e 


- reprezentarea; 
- algoritmii; 
- limbajul ín care se face implementarea. 


à Ín general, există o legătură strânsă între reprezentarea TD si algoritmii folosiţi pentru 
implementarea operaţiilor, dar şi în acest caz, la aceeaşi reprezentare, se pot concepe algoritmi 
distincţi pentru aceeaşi operaţie. Pe de altă parte, LP gazdă impune restricții atât in ceea ce 
priveşte reprezentarea, cât şi algoritmii folosiţi, programatorul fiind obligat să folosească resursele 
(TD şi instrucțiunile) acestuia. În concluzie, în implementare trebuie luate decizii importante 
privind concretizarea TD. Lăsând la o parte alegerea LP, ne vom concentra atenția asupra 
reprezentării şi algoritmilor. 
In fond, eficienţă unei aplicaţii poate fi văzută ca o rezultantă a eficienței individuale a 
TD ce concură la realizarea ci (neglijând intenționat aici performanțele calculatorului, 
programului traducător şi LP gazdă, tocmai pentru a accentua importanța implementării). Plecăm 
de la ideea că implementarea FD trebuie să satisfacă criterii de eficienţă dictate de sfera de 
utilizare a acestuia (mai generală sau strict dedicată unei probleme concrete). Aceste criterii pot 
viza în principal două resurse: memoria calculatorului şi timpul-de execuţie al operaţiilor sale. 
Criteriile amintite sunt în general antagonice (o operaţie cu timp de răspuns mic necesită 
informaţie suplimentară, deci mai multă memorie), aşa cà de cele mai multe ori soluția 
convenabilă este un compromis care le satisface pe amândouă în limite rezonabile. Există însă şi 
situaţii ce se încadrează la poli opuşi. Spre exemplu, în cazul aplicaţiilor în timp real (conducerea 
unor procese cu ajutorul calculatorului, rezervări de locuri la companii aviatice, feroviare, 
hoteliere), criteriul timp de răspuns este esenţial (se consideră că sistemele de calcul pe care 
asemenea aplicaţii funcţionează posedă o memorie şi o capacitate de calcul corespunzătoare 
volumului mare de informaţii şi timpului rapid de reacţie). La celălalt pol se situează aplicaţiile 
ştiinţifice sau cele de gestiune tradiţională, în care nu criteriul timp este esenţial, ci posibilitatea 
execuţiei pe sisteme de calcul de mică anvergură, cu memorie internă şi externă redusă şi cu 
unitate centrală lentă. Mâi mult, la aceeaşi aplicaţie, volumul datelor supuse prelucrării poate să 
impună cfiterii diferite de eficienţă, care se vor reflecta in implementări diferite. De exemplu, 
evidenţa personalului pentru 100 de angajaţi sau pentru 100.000 de angajaţi înseamnă de fapt două 
aplicaţii diferite. Dacă în primul caz accesarea unui angájat se poate face parcurgând secvențial 
mulțimea acestora, fără mari impedimente, în al doilea accesul secvențial nu poate fi luat în 
considerare, indiferent de cât de mic ar fi timpul de acces la o înregistrare. 


Chiar şi în domeniul calculelor ştiinţifice pot apare astfel de situaţii. Este binecunoscut 
faptul că TD numerice predefinite în LP (nivelul virtual) se bazează pe TD numerice ale maşini 
„(nivelul fizic), operaţiile aritmetice simple pe primele fiind realizate cu ajutorul proceşoarelor 
aritmetice (hard). -Pentru ‘calculatoarele compatibile IBM-PC, arhitectura standard a 
microprocesorului nu conţine decât operatorul (unitatea de calcul) de aritmetică întreagă, 
coprocesorul matematic (care este de fapt operatorul pentru aritmetica pe numere reale) fiind 
opțional. În'consecinţă, toate operaţiile pe numere reale sunt simulate ču ajutorul operatorului pe 
întregi, o simplă adunare reală însemnând mai multe operaţii aritmetice întregi (se milica 
nivelul fizic pentru implementarea soft a aritmetici reale, în aşa-numitele emulatoare). Mai muli, 
în cazul în care precizia de reprezentare a numerelor întregi sau reale (cea de la aieh fines 
propagatá si la nivelul virtual) nu satisface cerințele problemei de rezolvat, se pot proiecta ca Weg 

utilizator numere în precizie (aşa-zis) infinită, care vor avea ca operații esenţiale cele aritmeti 
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În acest caz o precizie sporită are ca efect creşterea considerabilă a timpului de execuţie, deoarece 
operaţiile noului TD numeric nu vor avea un corespondent direct în operaţii maşină, ele fiind 
implementate pe baza operaţiilor existente în TD predefinite ale limbajului (de data aceasta se 
utilizează nivelul virtual pentru implementarea aritmeticii). i i 


Dintr-un alt punct de vedere, în cazul TD structurate mai apare o problemă: modul în 
care elementele sunt dispuse pe suportul fizic (memoria) si, legat de această reprezentare, cum 
pot fi ele accesate. Plecám de la ideea că există mai multe elemente (realizări, instanţe) ale TD, 
care ocupă, fiecare, o anumitá zonă de memorie externă. Există două tehnici de bază pentru a 
regăsi un anumit element, care de fapt transpun două dintre tipurile de relaţii discutate anterior: 

= pezițională; | ' 
s legată. 
Regăsirea pozițională presupune determinarea adresei fizice a elementului căutat. prin 
calcul, cunoscând numărul de ordine-al elementului si presupunándcá toate elementele au aceeaşi 
“lungime de reprezentare. Prin urmare, ca se bazează pe o relaţie de ordine stabilită pe mulțimea 
elementelor, definită de poziţia (adresa) pe care elementul o ocupă în memorie. Dacă se poate 
determina adresa prin calcul, regăsirea este rapidă. Din-păcate, o astfel de tehnică este puțin 
flexibilă, deoarece introducerea unui nou element între două deja existente sau ştergerea unui 
element sunt destul de costisitoare, necesitând. recopierea (translatarea) unci părți dintre 
elemente. | 


modificarea informaţiei uire, Această tehnică foloseşte relația de liniaritate a structurii 
fiecare element are un uni S : | 


V H 
1 


3.4, TIPURI DE DATE LA NIVEL FIZIC ŞI VIRTUAL 


În paragrafele precedente, am discutat cele trei nivele de considerare a TD: abstract, 
virtual şi fizic. Discuţia se peate face de pe două poziţii distincte: cea a proiectantului, respectiv 


iu vA 


cea a ufilizatorului. = CSS 


` 34.1. Tipuri de date la nivel fizic 


începuturile ciberneticii, calculatorula fost conceput cao copie a minții umane. Putem 
discuta E iara unitatea sa prelucrare (creierul), memoria şi dispozitivele de legătură 
cu mediul extern, numite periferice (similare organelor de simţ). ES 
“Din punct de vedere structural, componentele unui calculator sunt memoria şi unitatea 
de prelucrare (procesorul). Fiecare dintre aceste componente au, la rândul lor, mai muli 
reprezentanţi si ele vor fi discutate în cele ce urmează. Discupia va fi făcută considerându-le ca 
|; | ` 3411. Memoria — | 


Memoria calculatorului este mediul de stocare a informaţiei prelucrate de calculator. 
“Clasificări ale memoriilor se pot face după: 


` 


„ internă (conectată direct la unitatea de prelucrare); z 

„externă (accesibilă unităţii de prelucrare prin intermediul perifericelor); 

- tipul de acces: secvenţială sau cu acces direct; ` 
- timpul de acces: rapidă sau lentă. 


Memoria „internă a calculatorului prezintă diverse particularităţi constructive Şi 
funcţionale. În linii generale, clasificarea memoriei interne se face după dimensiune şi timpul de 
acces (care dictează preţul) si include: — 

- memoria RAM (Randoim Access Memory), care este memoria internă obişnuită, 
caracterizată prin pret mediu, timp de acces şi dimensiune, în general mare; 

- memoria ROM (Read Only Memory), ce poate, fi doar consultată, cu aceleași 
caracteristici de timp de acces şi cost şi de dimensiune în general inferioară 

„> = memoria cache este o parte a memoriei RAM, caracterizată prin timp de acces extrem 

` ES de mic şi prin cost mare; : e 
- registri generali ai procesorului, cea mai scumpă si în acelaşi timp cea mai rapidă 


memorie. D ` 
; Memoria externă a calculatorului se caracterizează în general prin dimensiune şi. timp 
de acces mai mare decât cea internă. Criteriul esenţial de clasificare este modalitatea de acces, 
şi distingem două categorii: ` = ` d ARA : 
- memoria SAM (Sequential Access Memory), în speță banda magneticá, care se 
Ms caracterizează prin volum mediu, timp de acces relativ mare; dar are ca avantaj 
` portabilitatea; ME EC ES RW ; 

- - memoria DAM (Direct Access Memory), proprie dispozitivelor magnetice sau: ` 
magnetooptice cu suport adresabil, cu timp de acces destul de mic (de ordinul 
milisecundelor) şi cu o largă varietate dë capacităţi (de la un megabyte, pentru 
discuri flexibile, la gigabyte). MEINES 


pt 


- Indiferent de tipul ei, memoria poate fi văzută ca o succesiune de locaţii în care se poate ` 
stoca informaţie în format binar. Unităţile de măsură folosite sunt: ` & : 
- ' - bit-ul, bistabilul ce poate memora o cifră din baza 2; ` ; 
- octetul (byte), succesiune de 6,7 sau (uzual) 8 biţi; x : 
` - cuvântul (format din 2, 4 sau mai mulţi octeți, dependent de calculator: 2 la PDP-11 si 
- majoritatea microcalculatoarelor personale, 4 la Felix C-256 sau IBM/360, 10 
- . la CDC Cyber); Ex E s 
es - Koctetul (KByte, 2” octeți) (K = kilo); ; 
H - = Moctetul (MByte; 2Kocteţi) (M = mega); 
f - Goctetul (GByte, 2" Mocteți) (G = giga); — 
- Toctetúl (TByte, 2'%Gocteţi) (T = tera). — . 


— 


; Bitul este cel mai mic nivel de organizare al memoriei. De obicci, unitatea adresabilà nu 
este bit-ul, ci octetul. Cuvântul este folosit de obicei pentru memorarea numerelor reale în virgulă 
flotantă. Multiplii octetului sunt folosiţi pentru a exprima dimensiunea memoriilor (internă si 
.externá). ON : uma p I d EE Oli aie PANNE e 
Tix O locaţie adresabilă de memorie este caracterizată de următoarele atribute: adresă, - 
lungime și valoare. Operaţiile proprii tipului fizic de date memorie sunt: scrierea, citirea şi 
calculul de adresă. Citirea si scrierea presupun în prealabil calculul de adresă, 


3.4.1.2. Procesoare 


o A RS vise de la e Nu E 
l K SC T d D H 13 s s 
exact, putem defini procesorul ca dispozitiv (fizic seu virtual) Care. s Yuma ade 
- recunoaşte o anumită clasă de tipuri şi structuri de date; 
. ; poate executa un set de operaţii cu datele respective. 
O primă clasificare a procesoarelor derivă din definiţia de mai sus: fizice și virtuale. 


. Procesoarele fizice sunt unităţile de prelucrare ale calculatoarelor Există astăzi 
ASA ic prelu . Există astăzi o mare 
an procesoare fizice, unele produse în milioane de exemplare, altele unicat. Între acestea 
= microprocesoarele: 18080, Z80, 18086, 180x86, Motorola 680x0; i 
- unitățile de prelucrare ale calculatoare rhini/medii/mari/super: PDP-11, IBM/360, 
IBM/370, CDC Cyber, Felix C-256, VAX, AS-400, CRAY X/MP etc. 


Aceste unități de prelucrare pot fi, la rândul lor, déscompuse în module fizice, çu funcții 
particulare: ; À 

— procesoare de intrare/ieșire (1/0); 

- procesoare aritmetice (întreg, real); 

- unităţi de comandă; eS 

- procesoare scalare sau vectoriale in cazul arhitecturilor paralele. 


` Din punctul nostru de vedere, putem considera procesoarele fizice ca tipuri de date, aic 
cáror domenii sunt constituite din domeniile TD ale memoriei interne, conținând următoarele 
elemente: bit, octet (byte), cuvânt, registru, adresă, întreg maşină, real maşină. Operaţiile proce- 
Soarelor (văzute ca TD) sunt comenzile (instrucţiunile) maşină. Datorită caracterului primitiv, 
elementar şi extrem de rudimentar ai acestora (codurile operaţiilor sunt numere), scrierea.de 
programe în limbaj maşină nu este folosită decât în situaţii speciale. Prima etapă după limbajul 
maşină în evoluţia limbajelor de programare a constituit-o apariţia limbajelor de asamblare, care 
ataşează unei comenzi maşină o mnemonicá, mai uşor de înţeles decât un cod numeric, iar a doua 
limbajele de programare (de nivel înalt). ; 


Procesoarele virtuale se pot considera tot în maniérá ierarhică. Astfel, peste nivelul 
(procesorul) fizic, se suprapune primul nivel virtual, sistemul de operare (SO), ce asigură 
interfaţa cu utilizatorii, la începuturi propriu unei bine definite másini fizice. Astăzi se observă 
tot mai clar tendinţa de unificare a SO, concretizată în Unix. TD uzuale ale SO sunt fişierele, 
înregistrările şi octeţii, iar operaţiile formează ceca ce numim comenzile SO. Limbajul de comenzi 
al SO diferă de la un SO la altul (Job Control Language pentru IBM DOS/360, Command 
Language Interpreter pentru DEC PDP:11 RSX-11/M, Shell pentru Unix, CP/M pentru maşını 
cu i8080 sau Z80, IBM OS/2 pentru PS/2). Pe aceeaşi maşină pot coexista SO diferite, deci 
limbaje de comenzi diferite (pe IBM-PC şi compatibile coexistă IBM-DOS, MS-DOS, DR-DOS, 


versiuni de Unix). - E 3 i z 
Peste SCH prim nivel virtual se suprapun următoarele nivele de procesoare virtuale; ce 
pot fi lansate prin comenzi ale SO. Fárá a avea pretenția că enumerarea este completă, se pot 
2: d ici: j s jl * : SA D ` D Ca 
[S S programele traducătoare ` (translatoare), numite $ procesoare de limbaje: 
“compilatoare, asambloare, interpretoare; IOS > 
^ Gees (procesoarele) de texte (EDI, EDT sub RSĂ-AUM, No 
WordPerfect, Ventura Publisher, PageMaker sub S- ` 


FrameMaker); i; ZA ze 


Y 


XX 


D 


- PE Bride utilitate (Norton, PCTools, XTree); 
- programele specializate în prelucrarea tabelelor (s € umite şi procesoa 
j preadsheet), numite şi procesoare de 
; tabele (Lotus 1-2-3; Borland Quattro, Microsoft Exeel); ecu 
: sisteme "i gestiune à buzelor de date (IBM SOL, dBase, FoxbBase, Oracle, Socrate); 
programele coinerciale, ce acoperă o gaină foarte largă de domenii de utilizare: | 
= Proiectarea Şi prelucrárea asistată de calculator; i 
- prelucrările statistice; 
= învățământul asistat de calculator, ste; 
- progràmele utilizator; 


Dese AIRT o programere (începând cü cele de asarüblare) sunt ele însele procesoare 
ale, Altfel spus; LP pot f considerate că masini virtuale, o interfaţă între elementul uman şi 
maşina fizică, concepute ii ideea ușuirării muncii omului. Utilizarea lor este posibilă datorită 
existeiiței programelor traducătoare; Cü cât apropierea de limbajul uman este mai mare; eu atât 
procesul de traducere este mai complex. LP posedă TD predefinite şi (de obicei) meeanistae de 
definire a TD utilizator. Operaţiile acestor procesoare virtuale cónstituie setul de instrie[iuni al 
limbajelor respective: De obicei, o instrüejiune in LP corespunde ünei suééesiüni de instructiuni 
maşină. Dacă limbajul de programare în care se lucrează este standardizat, scrierea uri program 
nu trebuie să ţină cont de maşina pe Care se va execüta acesta, ci doar de algoritmul folosit: 
Dependenţă de mașină înseanină aici prezența programului traducător: Pe o aniimitá magina se 
vor puten dezvolta programe în limbajul Pascal, de exemplu, dacă între componentele SO al 
maşinii respective există şi ui comipilator Pascal. Acelaşi progra; tradus şi transformat în 
program executabil, va putea fi considerat la rândul lui o maşină virtuală, exprimată in 
instrucțiunile maşină ale câlculatorului gazdă (pe care a fost dezvoltat): Trecerea pe ün ali 
calculator (diferit fizic de calculatorul gazdă) a acestui program executabil nü este posibilă, 
datorită incotăpatibilităţii procesoarelor fizice: Singura modalitate de transfer între maşini fizice 
diferite rümáne cea de la nivelul virtual, dar iei aici portabilitatea nu este acoperită 100%; 
deoarece standardizarea LP este de cele mai multe ori numai un deziderat: fatre factorii ep 
îngreunează această standardizare mentionam: EE SE 

- diferențele ce ţia de concepţia procesoarelor fizice (dimensiunea Getetului şi à 

. . euvantului, facilităţile grafice şi sonore); . ` Med rcr 
- diferențele privind sistemele de operare (în special în sistemul de intrári/iesiri): 
34.13. Reprezentarea internă a tipurilor de date simple 


Ne referim aici la reprezentarea fizică a TD simple şi nu la modül in care coimpilatearele 
diferitelor limbaje de programare implementează aceste tipuri de ale. VE e. 
reprezentarea fizică a tipurilor de daté diferă de là ün calculator la altul, însă principiul tearetie 
de codificare este același: 


TFD inirég 


Principial; un întreg pozitiv este reprezentat în orice calculator pria şerierea sa în baza 
doi. Ceea ee poate să difere de la ün calculator la altil este lungimea locației E care Se De 
teprezentárea: Astfel, ealeulatoarele din generaţia a treia (FELIX €:356, H ARES 

reprezentau întregii pe un cuvânt de memorie format din patrü niet, làr e le e 
reprezintă întregii pe cuvinte formate din dei oeteţi. În toate sistemele poziția virg ü ei este stat ze 
ia mod virtual după ultima cifră binară şi nu poate fi modificata. De aceea reprezentarea se mái 
. püreste reprezentare în virgula fixă convenție aritmetică (fixed point representation à Ess? 
Reprezentarea numerelor întregi negative se tace folosind reprezent rea celor pozitive; 

trebuind în plus să se reprezinte semiul: Există două posibilităţi de reprezentare: 


(o 


date, Men[iosám. că. 


| 


- edificarea separată a semnului, urmată de valoarea absolută a numărului; 

i - complementarea valorii absolute. s EN a dă 

0j Med cediticări primul bit al primului octet este rezervat precizării semnului numărului și este 
) pentru numerele pozitive, respectiv 1 pentru numerele negative. í 

fom : Dacă locația are lungimea de 2 octeți atunci reprezentarea unui număr Je? se face sub 
fOFHa: > 1 


: Ca exemplu vom reprezenta, într-o locaţie de memorie de lungime 2 octeți, numerele 391 
și opusul sáu, -391. Deoarece 391 = (110000111), el va avea următoarea reprezentare internă: 


VAR Dati 


> 


NIS RA, Va 2 VÉ 


Pentru reprezentarea lui -391, se calcu lează complementul față de 2* a lui |-391|. Avem: 


| -  -30000000000000000 - 
-.. : 0000000110000111: . 


1111111001111001 
şi rezultă atunci reprezentarea: 


: Bin cele de mai sus rezultă că gama numerelor întregi ce pot fi înregistrate în. 
memoria calculatorului, folosind această reprezentare, trebuie să satisfacă relația -2" si s 2" A 
n fiind lungimea în biţi a locației de memorie in care se reprezintă numărul i. Deci: 


s NT =, 


e M i a ară e ae i ea ia EE, 
Operaţiile definite în TED întreg maşină sunt operațiile de calcul pe întregi (adunarea 
. seăderea, HEN împărțirea) si transferul între o locaţie de memorie si un registru: 


ervatie. În urma efectuării unor operaţii aritmetice asupra numerelor reprezentate 
în virgule f "n obţinute rezultate care nu mai pot fi reprezentate într-o locaţie de ee 
lungime. Avem în acest caz o depășire a capacităţi locației. Pentru a nu fi conduși la un rezultat 
greșit, prin trunchierea unor cifre ale părții intregi sau eventual pierderea semnului, aceste Sieg? 
suni memorate prin codificarea lor în indicatorii de condiție, de care se poate pne seama th timpul 


programării caleulatoruhii. s au E AIR 


t * 


e 


89 


` TFD real 


S În toate sistemele de calcul, 
otantă (mobilă) (floating-point re 
flotantà, acesta se scrie sub forma: 


pentru numerele reale se foloseşte reprezentarea în virgulă 
presentation), Pentru a reprezenta un număr real x în virgulă 


vs Mrt, beN, cez 


unde Me(-1,1), iar M, b şi e poartă denumirea de mantisă, bază, respectiv exponent. Se ştie însă 


: cio astfel de reprezentare nu este unică. De exemplu, în baza 10 avem: 


102,224*10* —0,0102224*10' = 0,102224* 10? = ... 


Acest inconvenient este înlăturat prin considerarea acelei repr if : 
d 1 ezentári in e 
verifică relația: | > p ări în care mantisa 


D 


b! <|M|<1, 


numită reprezentare normalizată. 
Din cele de mai sus rezultă că pentru a reprezenta în virgulă flotantă un număr real, lungimea 

locației în care se face înregistrarea ar trebui împărțită în 4 câmpuri (zone), prin care să se 

precizeze: semnul mantisei, valoarea mantisei, semnul exponentului și valoarea exponentului, 


- Ds] valoare exponent [s | valoare mansi | 
unde s, respectiv s' reprezintă semnul exponentului, respectiv al mantisei. | 


Ga Pentru a reduce numărul acestor câmpuri la trei, se utilizează „diferite convenţii 
. particulare de reprezentare în virgulă flotantă a numerelor, ce pot diferi de la un tip de calculator 
la altul. În continuare, concretizăm două astfel de convenţii, pentru calculatoarele FELIX C-256 

si IBM-PC. cC "us f y : 
- În cazul calculatorului FELIX C-256 se coâsideră b = 16, iar reprezentarea se face pe un 


` cuvânt de patru octeți. Pentru a renunța la semnul exponentului (s), acestuia i se adaugă un 
deplasament, introducându-se caracteristica, notată prin C şi care se consideră nenegativă, adică: 


; . C=e+d20 


Considerând locația de lungime 4 octeți =32biți, reprezentarea se face astfek ` ` 
EE "05 8 ADE Bae Da ese DIS 31: eta 


D © + ^ 


unde s reprezintă semnul.mantisei şi ocupă primul bit al primului octet, iar C este caracteristica, 
ea ocupând restul de 7 biţi din primul octet. Pentru reprezentarea mantisei se folosesc, aşa cum | 


" ^ 


Pentru reprezentarea numerel i i 

ent p or negative, se consideră complementul faţă de 23? 

reprezentării valorii absolute a numărului dat. Deoarece r istici Ce S 
CI ! l S eprezentare 3 

pe 7 biţi, valoarea ei maximă este: r S SE Eier 


1111111), = 127 
de unde rezultă că: ( h ` 
C =e +d< 127. 


Se deduce astfel că d nay =64, deci -64 < e < 64. 


; Ca exemplu vom reprezenta in virgulá flotantá numerele reale 3,390625 si -3,390625. În cazul "e 
primului număr, se obțin succesiv: .. e r EE 


E ` (8,300625). = (0364),5 = (0,364), x 16! - 
leci i SE SR 


prin urmare reprezentarea (în baza 16) este: ^ - Se 
ess] 
f În cazul numărului 3,390625, f osim reprezentarea precedentă,obținută pentru valoarea 
absolută a numărului şi. facem complementarea ei: Rezultă următoarea reprezentare ` 
hexazecimală: SAR ; : - 


4 


observându-se că valoarea bitului semn este 1, numărul fiind negativ. 
În cazul calculatoarelor compatibilecu IBM-PC reprezentarea numerelor reale în virgulă 
flotantă se face pe o locaţie de lungime 6 (octeți), baza de numerație considerată fiind b=2. 


Primul octet (biții cu numerele 40-47) este rezervat reprezentării caracteristici C, care este dată 


E dei ce] RE A D RE a a 
: : DAC SE E SENE à 
. unde (80). g este deplasamentul, iar ceilalți 5 octeți se folosesc pentru reprezentarea mantisei, i 
EE Lacs : i 
Hr AT. go e d$ n CR Mame 


; cel mai 
M Moo semnul 
semnificativ fiind o i având valoarea 


0 pentru "plus" şi 1 pentru minus"). Cel mai puţin se 


A 


H * a 


È 


! 
à cárui türepistrare se neglijează. 


Voin exeriplifica reprezentánd în virgulă flotantà iuni: 75.125 si 8 | siu: Rente 
à numarul 675,12 :P 
primul numiür aveti Biiccesiv: d SC 5 55i op üsül si: Pentru 


ti = 675,125 = (243,2), = (0010 1010 0011,0010), : 
Forma normalizatà a lui n va fi: , 
(e) & = (0,10101000110010); x 2” 
iar valoaréa caracteristicii: 
C = (80) + Un = (8A), = (10001010); 

Pentru reprezentarea maniisei se foloseste gett! cel mai sémhificáliv, care va conține 
succesiunea de cifre binare 00101000. Pinul bit a fost setat pe zero; întrucât în reprezentarea 
normalizatà primul bit este întoideauiia 1 și deci el Jen să ru se serie, locul lui fiind luat de bitul 
semi, Octetul imediat următor và conţine resțul de cifre binare; 11011000, iar eeilalii octeți ai 
mamtisc) sunt nüli; În final se obţine reprezentarea: | j 


M TL ia 


066000 6000096 [60000966 691688 [6061606] 


momma 


Gperaţiile definite în TFD real imagina sunt cele aritmetice pe numere reale (adunarea; 


el 


schderéa, fnmullireá şi împărțirea) si transferul între o locaţie de memorie şi ün registru; ambele 


de dimensiune egală cu lungimea de reprezentare à unti Da real. : 
Observaţie. Este foarte important de ştiut în activitatea de programare că ua Duer seal 


/ "AS nin Ap docas nEn ARRA p ` a m i mai 
| se poate reprezenta în calculator decât prin aproximarea murmarului în cauză eu eel mal 
apropii ae Feal réprezentabil. Există © infinitate de numere reale, dar pe B ERES de Ze? 
(Oricât ar fi ñ finit) se pot reprezenta nümai un număr finit de numere Si É 4e d 
că € este eroarea de reprezentare d ünui număr real; aluiici toate Rümerele re s Ce 
-(r- E--€) vor avea aceeaşi reprezentare: Prin urmare; rezultatul unei operàji i j 


. operanzi umere reale nü es e rezultatul exact din matematică ei Cel Mäi apropiat real 


nere d lar). Afirmahile de mai sus sunt adevărate numai pentru auinerele reale 
(reptezentabil în caleulator). Afirmațiile de mai sus sunt adevárate nümal pentru WITT 
(eat ervalul (sy) in SCH ín care si rezultatul operaţiei este îi Guck v Aind eel mal mare real 


f 
i 


—— 


ce se poate reprezenta într-un anume calculator. 


TFD caracter 


i Pentru orice calculator, dome niul S al TED caracter este format din cifre, litere, caractere 
speciale, etc. Pentru a putea codifica mulțimea S; numărul de cifre binare necesare codificării va 


de corespondenţă care permit introducerea unei rela de ordine între aceste caractere. Astfel, 
litera A să fie înaintea literei B, cifra 7 înaintea cifrei 8 si după cifra 6, etc. Asemenea codiiri 
foloseşte, de exemplu, calculatorul UNIVAC. è 


Cele mai folosite sunt însă codurile alfanumerice de lungirie 8, folosite de către 
calculatoarele IBM/360 şi FELIX C-256. Uii asttel de cod oferă 256 de combinaţii distincte; 
suficiente pentru codificarea oricărei mulțimi S cu mai püpin de 256 caractere. Deci cü ün cod bloc 
de lungime 8 pütem codifica cifrele, literele; caracterele speciale precum şi o serie de comenzi 
dàte calculatorului. í SS É 

Aceste coduri au fost standardizate sub denumirea de ASCII (acronim pentrü American 

. Standard Code for Information Interchange) şi EBCDIC (Extended: Binary Coded Decimal 
Interchange Code). De exempli; 
E:S = (Bj 
H:S = (Bu) 


deci pentru codificarea cifrelor zecimale şi literelor, în cazil codului EBCDIC, se folosesc 
-~ următoarele combinaţii de cifre binare, prezentate în tabelul 3:41: 
R N H 


La nivelul fizic nu putem vorbi de operaţii proprii TD caracter Folosiiidu=se reprezentarea pe un 
octet (în general); operațiile sunt cele ale TFD byte (de la TFD memorie). : 


TFD Boolean ` 


Domeniul tipului de date Boolean are doar două valori: TRUE şi FALSE. Pente à 
reprezenta în calculator aceste valori este suficientă o cifră binară; codificând prin 0 valoarea 


` TRUE şi prin 1 valoarea FALSE. . : 


Toate calculatoarele reprezintă insă aceste valori pe câte up octet, acestă fiind cea mai 
mică locaţie de memorie adresabilă. Codificarea valorii FALSE se face prin toate cele opt cifre 
binare ale octetului egale cu zero. Orice alt conţinut al octetului (deci care conţine cel puţin un 
1) reprezintă valoarea TRUE. Operaţiile TED Boolean sunt and (ŞI logic); or (SAU logic) şi not 
(NEGATIA logică). Ele sunt realizate fizic cu ajutorul circuitelor logice: 

3.4.2. Specificarea tipurilor de date virtuale. 
TD virtuale sunt precizate la nivelul limbajelor de programare: De obicei; implementarea 
lor se realizează folosindu-se TD la nivel fizic. Ne vom referi in continuate la TD simple, care se 
pot împărţi în două categorii: predefinite si utilizator. Pentru acestea vom prezenta pe scurt 


^ specificarea lor abstractă; 


D 


93 


caracter Cod EBCDIC 


11110000 
11110001 


11111001 
11000001 


11001001 
11010001 
11011001 
11101010 
11101001 


c 
[U 
1 
A 


nar 


TVD predefinite 
| TVD integer 


t 


| 
i 

S ; E Tabelul 3.4.1. Codul EBCDIC EE 
1. cd sunt numerele î inicgi i din intervalul [:MaxInt, Maxint], deci 


-Maxlnt sis Maxint SC i ; : 

unde Maxint are Valois dependentă de implementare. ` Pr NS 3 
:2. Relaţii structurale: de ordine şi liniară. Aw Fe 
i 3 Mulgi a operațiilor este dependentă de implementare, dar î în mod obisnuit confine: | 


x HENCE Operații aritmetice: © +şi- : : (unare) ` 
: * div, mod, +,- AC (binare) ` | 
Operații rèlaționale: ; | =,< >, <, < =,>, > = za 


- Operații funcționale: abs, sqr, trunc, round, 
` succ, pred, ord; i 
4. Implementare: se foloseşte TD fizic integer, care determină lungimea : de implementare p 
şi, deci, valoarea lui MaxInt. Pot exista e denn reprezentanți ai TVD integer, | 
D 


: care diferă între ei prin: 7 S t 
: valoarea constantei MaxInt `` j S È 
, d . prezenţa sau Se semnului, deci a a numerelor MS S i 
MN y r ` à : A EZ 
TVD real A aie e. EE RE NUS m 


1. Elementele. sunt DE EE r dintr-o ER finità a mulțimii numerelor 
e reale, care este dependentă de implementare. SESS LE 
=s . 2. Relaţii structurale: de ordine. 

219 Mulțimea, operațiilor este. dependentă c de implementare, da în mod obisnuit conţine: 

Opera aritmetice: + şi- d 
dE E e pete sai e EPOR ENS SY N (binare) 
Operații EECH SEENEN EEN >>. ; ; S 
Operații funcționale: abs, sar. sin, cos, arcam, pomis i 

WEE ERATEN d ` SS 


s Implementare: se foloseşte TD fizic real, care determiná | 
a ă lungimea de implement 
ŞI, deci, domeniul tipului. Pot exista reprezentanţi diferiţi ai TVD em diferă 


prin: 


lungimea reprezentării; 
tipul de reprezentare internă ales, 
un criteriu m def fiind prezenţa operatorului aritmetic real în arhitectura calculatorului 


(coprocesor EE 


TVD caracter 


1. Elementele fac parte dintr-o mulţime finită de litere latine, cifre, arabe şi simboluri 


speciale, 
2. Relaţii structurale: de ordine şi liniară. - à 
3. Mulțimea operaţiilor conţine: : 
Operații relaționale:  =,<>,<,<=,>,>= n» 
Operații funcţionale: auer, pred, 'ord, chr i 
4. Implementare: un caracter c este reprezentat ca întreg pe un octet prin codul lui, dat 


de ord(c) ` e SI 
TVD boolean -. |  /— OSEE 


1. Există două aud posibile: true şi false. 
74 “Relaţii structurale; nu este necesar ca TVD boolcin $ sá fie ordinal sau liniar; in 


Standard Pascal, acest TVD pus ambele ee structurale amintite. 


^ 


S 3. Mul(imea operaţiilor confine: : 

b Operati logice: „mot „n (unară) 

: ` and, or ` s ly rao (binare) 
Operatii funcționale: ord  - S Pi Ea Azi SS 


1 4. Implementare: existá diferite maniere de codificare: 
E — (0 = false, 1 = true), (0= false, *0— true) etc. 
j i În Standard Pascal true şi false sunt constante predefinite cu E < ord(true). 


A 
KS 


E TVD utilizator simple 
TVD enumerare ` SES EE EE | a 
: 1. Elementele sunt specificate sub Gs unei liste de “literal, (e formează domeniul : 
: te fnit. - è E 


: TVD), separați prin: virgulă. "Evident, domeniul es 
-2. Relaţii structurale: de ordine şi i liniară. Lista de definire a tipului induce ambele enu 


3. Mulțimea operațiilor conţine: — - o 
Operații relationale: - RUNS <=, Cer >= VERE cs CE 
“Operații funcţionale: succ, pred, ord s 
4. E compilatorul GE lista. de VERE a tipului enumerare, , iar 

valoarea unei variabile v de acest tip se reprezintă printr-un număr. întreg: 

ord(v) ` (poziţia pe care valoarea lu vo SE în cur de enumerare, 
mimerotarea incepând de la 0). : META 


TVD subdomeniu ` E 
PURUS GE finit al unui tip órdinal şi liniar, numit tip 
meniul. SS definit de cea mai mie especie cea mai mare. 


2 S Elementele fac parte 
Ei EE de pus, Subdo 


A c D 


valoare (în sensul relaţiei de ordine). 
2. Relaţii structurale: de ordine şi liniară. 
3. Mulțimea operaţiilor conţine: 

Operații relajionale: =,<>,8&, < =,>,>= 

Operații funcționale: suce, pred; ord , 
4. Implementare: compilatorul păstrează limitele subdomeniului, iar valoarea unei 
- variabile v de acest tip se reprezintă cu ajutorul FFD întreg; ord(v) ` — 


. 3.5, EXEMPLE DE TIPURI VIRTUALE DE DATE 


În cele ce urmează vom ilustra implementarea în Turbo Pascal a TAD specificate în 
paragraful 3.2. Datorită restricţiilor limbajului, numele modulului va fi compus din litera U (de 


la Unit) şi numele FAD. ` 


3.5.1. TVD Zile 
TAD Zile poate fi implementat natural în Turbo Pascal, folosind TVD enumerare. 
Remarcüm parcurgerea. circulară a domeniului SAP pentru operațiile Teri si Mâine si 
implenientarea acestora ca subprograme de tip funcţie în Turbo Pascal: ` 
“Interface — : pm e 


“Zile = (luni,marți,miercuri,joivinerisâmbătă,duminică); . — .— 
KCN de KA SS (Zile este de tip enumerare) 
` Function Ieri(z:Zile):Zile; - : UAM SE Ca, CE ; 


Pro e Scrie(z:Zile); : 
3 > Procedure Citegte(var ZZile); — » : 
Implementation — — uc cle co S 


Function Teri(z:Zile):Zile; ` S 

- Begm EE Sopa aci UT : 
Ifz-lun | DRE UE ILU e e ; SE 
e... thenlen;z duminica Coo e 
S else Leni e Proc) —- —— 1. 


“End; { leri} | 


Function Mâine(z:Zile):Zile; S 


d 


E EEN 


then Liberă : = True 
else Liberă : = False 
| End; ( Liberă ) 


Procedure Scrie(z:Zile); ` : 
Var RN; 


s : String; 
Begin 
i Case z of : 
RN luni  :s:="uni; 
mari :s:= "mat: 
„> miercuri: s := miercuri’; ` 
JOI. pes of 
Vineri :s:= vineri; 
C SENS sâmbătă :s:;-"sámbátd; ` 
E duminică : s: = "duminică! ` 
Endi Ru oy 
i WriteLn(s) ` DEE 
zo EE 
. Procedure Citeşte(var z:Zile); . 
— S:String; 
Begin 


A: 


d N 


"marţi :z:= marţi, -  -— 
"miercuri" : z := miercuri, ` — 
joi E JOIA 255 x 
E Miner? :z:= vineri; ^^. EG 
a 39cám nr. = 2 AT PUR Ge : 

3 "sâmbătă! :z:— sâmbătă; - 


“End, i 1 0s d 
„End; ( Citeşte F o m 
End. { Unit Ok) 


US A 


5 


“duminică” : z:= duminică = ^ 


p 352. TVD Natural 0 


Sé: É 7. SCAN Eee RULES Ye D ONE diee AE AC Macs d d x "e x 
` ` Implementarea TAD Natural pe care-o prezentăm corespunde numerelor naturale ce se 
pot reprezenta în memoria calculatorului pe 4 octeți (intervalul [0..MaxLongInt], MaxLonglnt = 


] 21 
cont 


în Turbo Pascal). Un număr natural este deci considerat întreg maşină pe 4 octeți. Ținând 


$ acceastáreprezentare, implementarea TAD Natural se face extrem de simplu, folosindu-se 
„| "operaţiile tipului predefinit LongInt (aritmetice si relaţionale) din Turbo Pascal. Sugerăm alte 
2 „două modalităţi de reprezentare a TVD Natural, diferite de cea aleasă, care-să permită ` 


' | manipularea de numere naturale n > MaxLongInt, cu: 


[se mis 


H 


) id - | -7 reprezentat ca tablou cu MaxDim cifre (MaxDim constantă, elementul de tablou să fie de tip 


Byte si să conţină o cifră a numărului scris într-o bază Baza; elementul de indice va conţine cifra 


"| derangi = coeficientul lui Baza); ` 
| -nreprezentat ca listă înlănțuită, nod, 


2 H A Ei 


i al listei conținând ca informație utilă cifra / a numărului 


9 t, ; ^ a * i oi 


t 


7 


scris în KEE Baza. 


Y 


, 


Pentru fiecare dintre cele douá reprezentări sugerate, ip oile aL aia. trebuie refăcută, 
“plecând de la specificaţiile 3,2;2 si obținându-se astfel noi variante ale TVD Narya care vor diferi 
ca funcționalitate Se cea de mai jos doar prin domeniu. ` i 


H 


- Unit UNatural; ERE DER i EE I 
Interface . - ` : ; ` 
Type e SE Ss 
Natural = = Artan i | d 
vy dh [Natural se reprezintá ca tip subdomeniu 


: es i oia tipului Ge Login 
pacali MaiMare(nl; n2: Manca) EE EE 
Function Egal(nin2:Natural)Boolean; . ^ 

. Procedure Adună(n1,n2:Naţural; var n: Natural); ^ - E ` 
Procedure Scade(n1,n2:Natural; unu. NERIS ea iN 

` Procedure Ori(n1,n2:Natural; var n:Natural); Ro REC. eos 
Procedure Cát(n1,n2:Natural; var n:Natural) Ex MCap eee Ag euet 


NEN -Procedure LE ‘Natural; var n:Natural);. 

puse mplenentation m ORE: ENDE 

E ee Eroare(S: String); : ENN 
" Begin SORS Sues 
„Write. Eroare? x RS 
"Halt. ` 


„End, Bt Eroare Se 


| ENT 2) or Ep n2) 
EE , .thenn:-ni-n2 
Ce S: SAX: E OERE E else Bet = Se i 
| ur in pa E 


'n:=an1*n2 x depisirea) 
Ead [Of]. (nu este testată depășirea) 


Procedure Cát(n1,n2: Natural; var n:Natural); vx 
. Begn- - 
n:-—nl Div n2 
End; f Cát ) 


Íi Y 


Procedure Rest(nl, n2: Maruta var n: Natural) N Ws 
- ` Been EE í F9 
è -n:- BI Made EE E a 
Endj[Resb)] — S ME. 
End. { Unit UNatural + c qeu 


Din motive de- Sophia. a. EE la VON Adună şi. Ori nu este testată 
ce valorii maxime „reprezentabile, MaxLonglnt. Sugerám cititorului să realizeze singur o 
; altă "e a de SOL Operații, s în care a se. semnaleze eroare în cazul depásirii. ; 


D 


" wo ` 
4 


uicit TVD Sutine CER "s S 
iu E S lin plesiencarta TAD Sutime pe« care o S prezentia corisideră reprezentarea domeniului 
R^ acestui TAD ca subdomeniu al tipului predefinit Integer 4 din Turbo Pascal.. “Ținând cont de această 
A reprezentare, implementarea se face extrem de simplu, folosindu-se operațiile tipului predefinit 
| Integer (aritmetice si relationale) din Turbo Pascal. p meia si Sapiente oec ir se. 
3 foloseste! TVD Natural, prezentat în 35.24 d SE 3X : 
i Unit USutime; pu de VC NER RE E UTD SN 
E Interface. zi SS o S oper poA c IMMER IE 
E Uses UNatural; iot E EUNDI T OS e ta, pe CE 


38 : me Sutime - =0. 99; ` (Surime se reprezintă Ge SE SS 


a dins Siege] 


. Function Egal(s1, 52: e SE 
“Procedure: Aduná(s1,s2: Sutime; var nd atural; 5 var s:Sut 
Procedure Scade(s1, 52: -Sutime; Var Sutime); 25 


5 Implementation us A 

epa Procedure Errar tring); 
; „Begin 

WriteLa(Eroare: en SE 

-Halt .. Lone > 
Eid: {Eroare} s SERO AEN 
EREN Function MaiMare(s, s2: Sume) Boolean; EE 

A Ca “Begin 4 sie D S SS IST Za M VR s Sa 

rd ci ` MaiMare izsl > Ed fa cel a ISSUES E 
EU End; MaiMare ) ` E de at os ua I DES 


Function Egal(si,s2:Sutime):Boolean; 
Begin . 
Egal := s1 =s2 
End; { Egal } 


Procedure Adună(51,s2:Sutime; var n:Natural; var s:Sutime); ` 


Var . : 


1:— sI + s2; 
n := i Div 100; 
- s:= į Mod 100 
* End; { Aduná ] 


Procedure Scade(s;s2:Sutime; var s:Sutime); 
* Begin 3 s 


If MaiMare(s1,s2) or Egal(s1,s2) - `" 
then s : = s1 - s2 SE 
else Eroare('n1 < n2); WA. : 
End; ( Scade) . - ` ERES OU ba 
End. ( Unit USutime } el rosse ecu Ss KE 


` Analizând implementarea operației Adună, putem sugera şi o altă soluţie, mai generală: 
- Š - EE DËS : Ge ` a AFAN S ES S A S E a 
EE var n:Natural; vars:Süutime); > : 
: 122,03 : Natural; 3 x ASA : ch ae Š A Nx Sei n 
Begin : 1 E ER: : SS RU MS S x = RES oa x 
 nl:-SutimeToNaturalsl; ` ` GE 
_n2:= SutimeToNatural(s2); SEN 
UNatural.Adună(n1,n2,n3); EEN 
- UNatural.Cát(n3,100,n); exe dec SE EE 
UNatural.Rest(n3,100,n1); x T DEEST ax cH. 0o. 
- s:- NaturalToSutime(nl) ` . : 3 UNS SEES 
End; ( Adună) ` x a =i ; 
^ în care am folosit operaţii de conversie de la tipul Sutime la-tipul Natural (SutimeToNatural) şi 
invers (NaturalToSutime), iar calculele s-au fácut folosind operaţiile, tipului Natural. 3 


254 EHM 


i3 


— ^. Acest TVD este un exemplu de folosire intensivă a altor TYD (Natura Sutime) pentru 
implemientarea TAD Monede. Se remarcă calificarea operației cu numele modulului (în situaţia 
conflictului de nume). Folosirea operaţiilor relaţionalc ale TYD Natural (MaiMare, Egal) în locul . - 
- operatorilor relafionali (predefiniţi) este un exemplu de apel independent de implementare: dacă 
- TVD Natural ar fi altfel implementat (vezi sugestiile făcute în 3.23.1), n-ar. putea fi folosiți 
respectivi operatori, prin urmare codul sursă al TVD Monede (operaţiile MaiMare si Egal) ar 
trebui rescris). Utilizând operaţiile cu care a fost dotat TAD Natural, se obține o implementare 
mult mai generală şi mai flexibilă, care nu este afectată de modificarea TVD folosite in ea. 


€. 


Š 


Unit UMonede; 


Interface 
Uses UNatural, USutime; 
“Type 
Monede = Record 
Lei : Natural; 
C Bani : Sutime 
End; 
Procedure BanilnMonede(n:Sutime; var r: Monede); 
Procedure LeilnMonedc(n:Natural; var r:Monede); 
Function LeiDinMonede(s:Monede):Natiüral; 
Function BaniDinMonede(s:Monede):Sutime; ` 
Function MonedeÎnReal(s:Monede):Real; - 
"Procedure RealinMonede(r:Real; var s:Monede); 
Function MaiMare(s1,s2:Monede):Boolean; 
Function Egal(s1,s2:Monede):Boolean; `. 
Procedure Adună(s1,s2:Monede; var r:Monede); . 
Procedure Scade(s1,s2:Monede; var r.Monede); 
Procedure Scrie(s:Monede); 
E Procedure Dobanda Mee, d:Real; var i Monede): 


; cx EE 

SN Procedure E String); 
A Begin 

` WriteLn('Eroare? SEE ; 


Halt 
` End; { Eroare } ` 4 


A 


Procedure BanilnMoncdefe: Sum; var Monde). DE 


Begin ; ee MEL. 
3 + LEA E Sa | E SE 
des t :  BanilaMonede )- | 
: DES Procedure Agen ` 
: Begin : ; s 
Lei ce es : SE 3, - 
Lo E Ze 
p 7 LeliMonede]. Tf 


mgr e 


Function i LoiDiaMonede(sMoncde Natal, ` 


E „Begin ` xr * 
e "LeibinMonede : = ale = X E = ES 
; „End; t LeiDinMonede E: 2 


"Function BaniDinMonede(s: Monede): Sutime; E 
Begin 
BaniDinMonede : —s.Báni ` MOD qu 
„End; ( BaniDinMonede } EE 


e^ 


Function MonedeinReal(s:Monede):Real; 


Begin 
MonedelnReal : = s.Lei + s.Bani / 100. 
End; ( MonedeinReal ) 


Ner RealinMonede(r:Real; var s: Monede); 
ar 
| ` Integer; ` 
| Begin 
| i := Trunc(r* 100); 
| | / s aBan: = i Mod 100; 
| | dus s.Lei : = i Div 100 
| 


FI] * 
N | 


„End; | RealinMonede } - 


Begin j 

MaiMare : = (UNatural: MaiMare(sl. Lei,s2. Lei)) Or 

; ((UNatural.Egal(s1.Lei,s2. Lei), And . 

y dune MM. Bani, s2. Bani); 
“End; | MaiMare ]. Sh 


|| | ) ; ` Function MaiMare(s1,s2: Monede): Boblean; 


/ t | Function GE ZA Mon m Booleans , 


gs ne "Egal: It Bella Lei ew dud 
PENA E nece Sm Bani, Ly VO LAS 
Ge End; (Eg) - RISO de 


Procedure Aduni(e2A Monede, varr: Monede); Ng 


i We Natural CAE 

. Begin. | 

| NITORE Une tun Bandi QUITE 
A Mat ee ELS; mel Lei + s2Lei p ua Pise M epe 
VASE „End; (Adună ) ` mu TURISTA 


MIT 


Procedure Dobánda(s: Monede; ^d: Real; var f Monedo) EEN 

Begin EE te 
EN "äm SE 
„End; ( Dobânda } | beti A 


SC Y 

Procedure Serie(s: Mona s Se $ 
Begin . S 
RO White(s.Lei6); - 
. fs Bani <10 SE 
SE "then Write0',s. Bain à MU 
SAES E 2E Nar ca E 

ST "WriteLn( lei) ` E 
PACA 


(End (Serie) ` (ip oale a a usii CR A 
More Senda pz Monede var Mene SÉ EA BN a 
„Be egin e Py 4 

S MaiMare(si, =) Or i c 
SC EE 


then 
- If USutime. MaiMic(1. Bani,s2.Bani) 
^ then 
Begin 
3 r.Lei : = s1.Lei - s2.Lej - 1 
PRE r.Bani : = s1.Bani - ei Dani + 100 
D ; End 
else 
Begin `. 
r.Lei:= sl.Lei- 82. Léi; 
r.Bani : — sl. Bani - 82. Bani 
End SR & 
e AE < y ac GE 
Ge End; ( Scade) , UE d | 


End. {1 Unit UMonede r 


T DT Y Ao E H 


Y 


E PROGRAMAREA I DIRIJATĂ DE DATE. 

în M secţiune a capitolului, SE am dicil despre programarea dirijată de 
operaţii şi despre metodele de construire a: programelor! eare- apărţin acestei maniere de 
realizare a. softului, evidențiind. atât caracteristicile pozitive ale acestora, cât şi neîmplinirile. 
Acestea din urmă au dirijat eforturile. specialiştilor î în căutarea de noi. -metode de dezvoltare, care 
să le înlăture | (măcar. parţial). Astfel a apărut © nouă: manieră de concepere a produselor 
program, numită peesramare dirijată de date sau propramane bazată pe obiecte. 

KS » 

Programarea. dia ata de date. punc accentul pe WOLLE datelor. Am 'vázut în- 
secţiunile precedente ale capitolului de AE cá SEH tratarea la. nivel abstract a WEE de date 
se realizează următoarele: QU l 
i 2v 

: Ep Se pune accentul pe ope adike: asupra structurilor de date: acest SET se poate 

. rezuma prin. întrebarea: ; = SU RON 


t E y i " i 
SC 7, " 


SE operati usupra structurilor de date sunt necesare pentru a rezolva problema P» 
2. Sei ignoră detaliile de implementare à a SD, spre BEER de programarea dirijata de ` 

- operajii, unde toate au se proiectau dupa ce ER Dep 
deidat qo S E STER LUNA ke - 


3, Se ascund dralle dei im aplementare aSD, dea cunoscând doàr serviciile SE de 


pe A IET „ furnizori; e ^ CS EE 3 

y de SE ar a a e KEE pi KE 

e "A Termenul de modul 15 Pcr primeşte o nouă accepliune: d este o implementare 
QU TU EE apt de TAD (uliul saga mnlto " CULA i e 


E 

Ge descrise 
“Eta 74 care trebuiesc parcurse î în E programării i dirijate d dite au 
$i în "P ale acestui capitol.1 “Pentru fixarea jdeilor, prezentimi i rezumat EE 


„care DES E în succesiunea lor 


CH Identificarea structurilor: dE date erem e pentrur rezolvarea problemei şia operatiilor ` 


r 
vt ` PS REOR HANY KZ 


d 


d ^ Y, ^ ^ Sa ^ 
" L , * ^ A 4 
5 EAT RO 1 $E ae Rei A PL pn st 


asupra acestora, necesare pentru rezolvarea problemei P; | 


2. Proiectarea TAD corespunzătoare, cu includerea tuturor operaţiilor identificate în 


© prima etapă (si eventual a altora); în proiectare TAD se consideră independent 
de problema concretá P care trebuic rezolvată; 


3, Implementarea. TAD definite in ctapa precedentă; pentru aceeaşi abstractizare poL 
exista mai multe implementări, echivalente semantic; implementarea, în care se 
concretizează structurile de date pentru reprezentarea TAD şi algoritmii 
operaţiilor va ţine cont de limbajul de programare folosit si de caracteristicile 

o problemei de rezolvat; 


:4. Proiectarea si implementarea subprogramelór necesare pentru obţinerea funcţiilor 
programului, care vor utiliza TAD implementate deja, utilizarea TAD se va face 
fără a ţine cont de implementarea lor, ci doar de operaţiile pe care acestea le 
posedă; altfel spus, se vor luă in considerare doar serviciile oferite de TAD 
proiectate. ERR : SE : 


» 
£ 


E 


LA 


S Metodele de proiectare dirijată de date au apărut după anii "70, fiind influențate de 
facilităţile de modularizare existente în limbajele de programare care au fost realizate în perioada 
respectivă (MODULA, Ada, Euclid sa) Asupra limbajelor de :programare folosite. la 
implementarea TAD se impun câteva cerinţe importante, care, de altfel sunt satisfăcute de 


aproape toate limbajele de nivel înalt contemporane! Astfel, un limbaj adecvat acestei maniere 
de programare trebuie să posede: TES ; Mee 
1. Mecanisme de íncapsulare; ` f t o 


2. Mecanisme dè ascundere a detaliilor de implementare; 


53. Facilităţi de modularizare şi compilare separată; S 


4. Mecanisme de instanţiere a TAD (instanțele TAD vor fi numite obiecte, de unde şi 


: - numele de programare bazată pe obiecte); e E ET 
e ctae. 8: Mecanisme pentru alocarea şi dealocarea dinàmicá a obiectelor: (eventual apelate 
zi S i- automat); . Zar e ae [CROP i RD EAI Tae e ASE i 
zé Oe J S Kg AS CA x re E KH - - 2 


- . 6. Facilităţi de supraincárcare a operatorilor, uşurând exprimarea, 


EE Qn o S 
T SOON : ve cent x EN ATE D S CE 3 S ; purus Ev 
Dintre. aceste, cerinţe, primele trei. sunt. esenţiale, proprii abstractizării datelor. 
- satisfacerea de către un limbaj de programare particularia ultimelor patru oferă o comoditate 
=.  porită implementatorului, mărind productivitatea în codificarea programelor şi sporind 


fiabilitatea componentelor soft realizate. ee 4 


` =~ i 
vr GE 


f Între metodele care pot fi incluse ín aceastà categorie, realizate in special in anii 80, — 
"menţionăm cele orientate pe pachete (având Ada ca limbaj de implementare): S 


Aë 


H 


SE EE 


Creşterea extraordinară (în special dupti 1980) realizati de industria de cul 
` programe a ficut ca si această manieră de programare sig Mop limitele, nereuşind să satisfach 
ur 


culatoare sí 


> integral cerinţele de proiectare şi întreținere a gamei extrem de gi de produse program de care 
este astăzi nevoie, Principalele dezavantaje ale metodelor de proiectare dirijată de date s-au 
revelat atât în fazele de concepție, cát şi în faza de întreținere a produselor soft realizate cu 
ajutorul lor. Între aceste dezavantaje men(ionüm: 


1. Nu cxploatoază ierarhiile de tipuri abstracte de date: mecanismele de încapsulare și 
protecţie a datelor nu sunt suficiente pentru exploatarea comunalităţilor; cu alte 
cuvinte, nu sc pot deriva noi TAD, pe buza celor existente Şi care să mogtencascii 
caracteristicile părinţilor: la proiectarea bazată pe obicete nu apare conceptul 
de moştenire; 

2. Comunicarea între module este greoaie şi explicită: acest lucru este evident maj ales 
în situația lucrului cu colecţii de obiecte polimorfice, când, pentru a exploata 

SA polimorfismul operaţiilor, este nevoie de specificarea explicită a TD căruia îi 
aparține o anumită operaţie, Evident, este vorba numai de polimorfism static, în 

„sensul că tipul fiecărui obiect este cunoscut la compilare; se va arăta în capitolul 


N ag SERA următor că realizarea polimorfismului dinamic este condiţionată de ierarhizarea 
SS "o ` TAD, deci de prezenţa moştenirii; Y 


3. Íncurajeazi.in mică măsură reutilizarea: cu toáte avantajele modularizarii $i. 
genericità[ii, se. poate vorbi cel mult de reutilizare de speța a ILa, în situaţia 
când limbajul de implementare posedă facilități generíce; .- 


sr" Tt 


^4. Rigiditate si centralizare a arhitecturii produselor realizate: există un modul principal 
care poate; fi considerat modul client pentru celelalte componente ale 
‘arhitecturii sistemului, soft; orice nouă specifica(ie implică modificări, atât în 
modulele furnizor ale programului principal, cât şi în modulul principal. Din 
: "nou, absenţa moştenirii face ca eventualele modificări ale apel ui serviciilor 
z -- (datorate includerii de noi caracteristici pentru TAD respective necesare într-un 
: ` ` anumit loc) să provoace modificarea tuturor apelurilor respectivelor servicii; în 
"prezenţa moştenirii, noile caracteristici ar putea fi incluse în TAD derivate, noi. 


4 tar d 


-. conservándu-se astfel sintaxa vechilor apeluri. ` ` 


^ 


EE | „CAPITOLUL 4 


d s 
DEZVOLTAREA ORIENTATĂ PE OBIECTE A 
PROGRAMELOR | 


4.1. PROGRAMAREA ORIENTATĂ PE OBIECTE ; 


CS Am văzut în capitolul precedent că programarea orientată pe obiecte este programareu 
bazată pe obiecte la care se adaugă două atribute noi: moştenirea şi polimorfismul. Înainte de a 
defini conceptele de moştenire $i polimorfism, vom face o scurtă trecere în revistă a conceptelor 
de bază legate de programarea orientată pe obiecte (Object-Oriented Programming, OOP sau 
POOL EE e UR Gi 

SUC 1 I: Noţiuni şi concepte fundamentale... + 
ră E 1 i NR 


< În programarea bazată pe obiecte (Object- Based Programming), obiectele încapsulează 
date (ce caracterizează starea lor) si acțiuni (care caracterizează comportamentul obiectelor). 
“Obiectele comunică între ele prin mesaje. Două obiecte de același tip (adică instanţe ale aceleiaşi 
clase) vor avea aceeași mulțime a variabilelor de stare (numite câmpuri sau variabile de 
instanță), dar vor avea valori diferite ale acestora, ce le va deosebi. În schimb, din punct de vedere 
comportamental, ele vor fi capabile să efectueze aceleaşi operaţii (metode); natural, fiecare obiect 
> va efectua o anumită operaţie in conformitate cu starea sa. Cu alte'cuvinte, două obiecte identice 
` (ca tip) vor reacţiona diferit la acelaşi mesaj, deoarece răspunsul ține cont de starea fiecăruia 
| direc ENSE ese AI qum Dm eri CLR 
p În preambulul de mai sus am folosit noţiunile: obiect, clasă, instanță sau realizare, câmp - 
` sau variabilă de instanjá sau variabilă de stare, metodă sau operaţie, mesaj. Să le definim. 


SN D 


l şi reprezentare (aceleaşi variabile 
destare, numite şi câmpuri sau variabile de instanţă) şi acelaşi Se operaţii, . 
oua niveles uie e 


S i Opes erae ede. e Ee se EE x 
< | Clasa este o mulţime de obiecte care au in comun áceeasi rep 


“numite metode). Conceptual; ea poate fi considerată 


ab La nivelul abstract: 
z e velasa este un tip abstr é 
de 055 705727 e; “câmpurile definesc reprezent EU 
m „operaţiile definesc comportam MCA 


— 4. 2. Lá nivelul virtual: 
-. clasa este un mecani 


S XIS| 


SC - - încapsularea datelor si operaţiilor; 
"stabilirea unor reguli de vizibilitate (acces la câr 
T pL de protecţie adatelo os EN T 
nume cantităţii respective (mecanism- de tipizare); . “ 


puri din mediul extern ci; mecanism 
| 105. - asocierea unui ii respective dem de tipi SAC NU 
ERES posibilitatea, creării Şi SE (realizărilor) sale (mecanism de: 
estate Constructori destructori)i e a erati 
Al ie UD so numesc vafiabile de instanţă sau variabile: de stare; operaţiile ` 


UU ; Kee şi VT m Paley HS eC we? ^ otocolul de. 
^. ere) se. pipese metodei mulliieu moteqelor clase formează, PETEN E 


1 Ý 
D MA Nn D NP Dk 
e EE H V Y MURS SIRO i. E at 
, H Ge d GC ` ; S 
KUER det erh A JO pi Ali i N > N 
di n d G P D ` S 
d " i 
4 "jf f | D x 
id r ^ v 
` 


gramare, ce permite: = = = S 


. 


e ^ 


comunicaţie al obiectelor ei, 


Deci, la nivelul abstract clasa este un ti 
este un tip virtual de date. 


H 


p abstract de date, iar în a doua accepţiune, clasa 


j 


“Obiectul este instanță (realizare) 
a clasei, în ambele deu discutate mai sus. La 
. La 
aeu virtual, putem considera obiectul ca o variabilă dc tipul clasei. Obiectele comunică între 
ele prin mesaje. În formă g generală, un mesaj se poate scrie astfel: 


E 


send(R,S[,A - 
VOUS (R,SSLA]) ` 

R(receptor) este obeki destinatar al Ge 
S(selector) este metoda apclatàá 


A(argumente, optional) contine parametrii actuali ai apelului 


Obiectul receptor R, instanţă a clasei C, poate răspunde la mesaje cu SET S numai dacă 
metoda desemnată de S face parte din protocolul de comunicaţie al clasei C. Altfel spus, S este 
quss unei metode d această metodă, trebuie să fie definită i în clasa C. 


` S "Vus pi 
ET 1. 2: Mostenirea şi EE UE o primă GE es 
` Definiţiile date în acest paragraf sunt imprecise, dar constituie, un punct de GE în 
e noastrd: Ele. vor fi detaliate î în secţiunile următoare. $ - 2 SC 
; 4 Mostenirea permite clasificarea obiectelorí in ind dania caracieristicilecomume: (de 
stare sau de comportament); ale lor. Polimorfismul dinamic i înscamnă trimiterea de mesaje spre 
„obiecte de tip necunoscut, dar care recunosc mesajul (selectorul acestuia face parte din protocolul E 
"de comunicaţie al clasei lor). “Numim obiecte polimortice acele bbiecte care au acelasi protocol . S 
-de comunicație. Împreună, moştenirea si polimorfismul suat instrumente ce Deren realizareaá - | 
două marideziderate: ` x Sa Se t "M 
WW organizarea ierarhiilor de clase; Sia f Ge E SE : 
- SE comunicării între obiecte. ARRA S x 


` ` j SZ 


e Cu. aceste, noțiuni precizate, se Sot formula două (pscudo)definii ale programării 
orientate pe obiecte (POO): S B 
: 1. Esenţa POO.: este irimiterea dé. mesaje spre obiecte de tip necunoscut, care au in. 

comun “acelaşi protocol de comunicaţie; 1 
A POO este un stil de programare, (mai bine zis de dezvoltare de programe) c ce încearcă 
aU minimizarca complexităţii unui ptogram prin reducerea numărului de conexiuni ` 
Sp tuu. TE componentele sale. Căile de reducere a orca sunt: ES 
fa, - transmiterea de mesaje; i : S 
/ uM DU T E - definirea unui protocol de comunicație simplu şi, în SP Smig general. 


H 


MS Je AE Etapele de les a unui program oricutat pe obiecte. respectă în general EE 
prezentate î în capitolul precedent la programarea bazată pe obiecte. Eilean S 
Da? > x A 
Ee Crearea de clase, ce definesc reprezentarea şi comportamentul obiectelor; ` 
ZE “2, Crearea de obiecte, instanţe ale claselor; A 
< 3, Crearea programului, văzul ca o secvenţă de comunicări între obiécte (programul! iind 


(E SE „un Şir: de mesaje): / 


A 


Aceste etape vor fi 
` observaţii: 


detaliate în secţiunea 4.3, succesiunea lor bazându-se pe următoarele 


1. În proiectarea unui program ceste nevoie de identificarea şi clasificarea obiectelor ce 
` Concură la realizarea funcfiunilor programului; 
2: Clasificarea obiectelor impuhe ordine, atât pentru sistemul real (o ordine naturală 
. Proprie acestuia), cát si pentru modelele sale (logic si fizic); 1 
3. Obiectele se clasifică după caracteristicile lor comune; ` 
4. În funcţie de locul de folosire a obiectelor, caracteristicile lor pot fi accentuate sau 
ignorate; i - 
5. Obiectele cu aceleaşi caracteristici se grupează în clase. 
H 


Să considerăm un produs program destinat evidenţei mărfufilor într-un supermagazin. 


s Ţinând cont de observaţiile de mai sus, primul lucru care trebuie făcut este identificarea 
obiectelor, În cazul nostru, sistemul real esté compus cel puţin din următoarele categorii de 
obiecte (fiinţe, lucruri, compartimente): măriuri, magazii, case de marcaj, standuri de vânzare, 
puo cumpărători. Dintre toate aceste obiecte, vom discuta în continuare doar despremărfuri. 

sistemul real (supermagazinul), obiectele (reale) care sunt manipulate (vândute) sunt mărfuri. 
Prin urmare am identificat obiectele reale şi urmează să le clasificăm. Un supermagazin 
comercializează o mare diversitate de.márfuri. Din multe considerente (o gestiune mai uşoară, 
atractivitate si uşurinţă în găsirea mărfii pentru cumpărători), spaţiul comercial al 
supermagazinului este împărţit în. raioane, a căror denumire carăcterizează genul de mărfuri 
comercializate. Uzual putem găsi raioanele: alimentar, textile, librárie-papetárie, tutungerie, 
cosmetice, încălțăminte, menaj, electrice, electronice, articol de lux ş.a. lată că sistemul real oferă 
oclasificare a mărfurilor, făcută dupădiverse proprietăţi ale acestora (provenienţă, utilizare): Este 
firesc ca aceastá clasificare naturală să se prelungească si în modelele logic şi fizic ale sistemului 
real. Prin urmare, putem discuta de obiectul MARFA, care aré ca descendenţi obiectele 
ALIMENTARE, TEXTILE, LIBRARIE, TUTUNGERIE, COSMETICE, INCALTAMINTE, 
MENAJ, ELECTRICE, ELECTRONICE, ARTICOLE DE EUX. X e 

- Caracteristicile comune ale tuturor mărfurilor le vom grupa în obiectul MARFA. In 
analiza care trebuie făcută, trebuie considerate obiectele din diverse puncte dë vedere. Pentru un 
cumpărător sunt importante funcţionalitatea şi preţul de vânzare. Funcţionalitatea este o 
caracteristică mai greu de cuantificat, motiv pentru care ca va fi tratată distinct la fiecare clasă în 
parte, însă preţul este extrem de important: în supermagazine diferite, aceeaşi marfă poate să aibă 
preţuri diferite. Din punctul de vedere al gestiunii magazinului sunt. importante şi alte 
caracteristici, ca de exemplu: codul mărfii (ce asigură o identilicare unică a ci), denumirea, 
unitatea de măsură, preţul de achiziţie, prețul de transport, adaosul comercial aplicat, TVA, stocul 
din depozit, intrări (achiziţie de marfă de la furnizori), ieşiri (vânzare de marfă). Unele dintre 
aceste caracteristici vor servi la determinarea preţului de vânzare. 
Caracteristicile de mai'sus sunt comune tuturor mărfurilor. Pentru clasele de mărfuri 
enumerate, se pot identifica si caracteristici specilice fiecăreia, ca de exemplu: > 


un VOU S NE SOR 
ALIMENTARE : termen de valabilitate. : $ 
TEXTILE : tip fire. ~ ; 
' ÎNCĂLŢĂMINTE: mărime Aa pea: 
ELECTRICE : pulere-consumală ., b 
ELECTRONICE : termen de garanţie e 
ARTICOLE DE LUX : accize 


N 


f 


RE Natural, fiecare din clascle de mărfuri mai sus enumerate, 

ees S "A, Vor avea toate caracteristicile acestuia, Se observă deja re 

€ bază conţine caracteristicile comune, iar pentru descendenţii a 
ce-i deosebeşte de părinte. ` S 


fiind descendenţi ai obiectului 
utilizarea specificării: obiectul 
cestuia se specifică numai ceca 


s carmine de mai sus, am identificat şi clasificatobiecte din sistemul real, determinând 

i acie comune sau specializate ale lor. Conform ultimei reguli (5), trebuie să grupám 
aceste obiecte in clase. Gruparea sc poale face numai după ce caracteristicile obiectelor 
“grupurilor de obiecte) sunt scoase în evidenţă. Claselor nu le mai corespundobiecte reale; clasele 
sunt descrieri abstracte ale obiectelor reale. Clasificarea acestor obiecte va forma o ierarhie de 
lase. Pentru exemplul nostru, ierarhia clasei MARFA este ilustrată în figura 4.1.1. Natural 
-iecare subclasá a clasei MARFA poate [i la rândul ci dezvoltată în continuare. : i 


1 


cod. Unitate de măsură stoc intrare 
3 denumire pret achiziție |, TVA ieşire * 
pret pret transport adaos comercial 


ÎNCĂLȚĂMINTE ARTICOLE DE LUX 


| ` |TEXTILE ELECTRICE | | ELECTRONICE 
| NA termen de tip, mărime -- putere ^ — termen de ^ accize 
: valabi- . . fire : - „consumată garanție 
bitate : > AES EE | 
S i Figura 4.171. lerărhia clasei MARFA | 
e ; | 


Odată claásele identificate, trebuie realizată specificarealor, când multe dintre elementele 


- discutate informal trebuiesc precizate. Astfel, unele dintre caracteristici sunt date, ca de exemplu | 
[Em denumirea, codul, unitatea de măsură; altele, cum este prețul (de vânzare) se pot calcula (pe baza | 
unui algoritm de calcul). Primele sunt ceea cc am numit câmpuri sau variabile de instanță, iar. ` 
17-7 e ultimele sunt metode ale claselor respective. Când am facut identificarea caracteristicilor claselor | 
|. nu am precizat dacă ele sunt câmpuri sau metode, Specificarea unei clase và cuprinde, într-o | 
| primă aproximaţie numele clasei, specificarea câmpurilor și specificarea metodelor. Schema | 
i generală de'specificare a unei clase este dată în figura 41.2. Sa e | 
= nume, identificator  .| IS 
^- | Campuri ~ > SE Specificare câmp. i 
„. specificare câmp] "| | “nume şi, explicație H SS 
Y ` specificare cámp 2 „tip de date ` SEC i 
E. x] 
S peci i care metoda m- ANA EH 
e Pigura 41.2: Schema de specificare a clasei ` | 
e Pentru clasa MARFA, schema de specificare este prezentată în figura 44.3 : in rațiuni 
Ap de spaţiu, numele unor caracteristici este trunchiat. E cae e datei cae 
pie Ai Z NA SO SCH uy e SEA S i-e SR $ t : éi : 3 
— ^0. ^ Revazâd schema de specificare a unui tip abstract de date, piedealale tn seuls i 
SC "(figura 3.21) putem constata Cá specificarea claselor respectă această schemă. Din moine ec. 
E z P GC X 1 ; i Va NS ` D. 
i Ü NON 
CLARA MEA è RN, | NS Eoo 


VET P 


opu: in gpeoncinie de mai sus nu am detaliat partea aferentá operaţiilor TAD (numite aici 
“metode). În. plus faţă de specificarea TAD, după cum sc va zs in paragraful urmátor, 
specificarea clasei conţine si alte elemente. 


4.1.3. Moștenirea 

. Mostenirca permite definirea de noi clase, pe baza celor existente (ultimele sunt numite 
clase de bază sau clase părinţi sau superclase). Noile clase astfel obținute sc numesc clase 
derivate, subelase sau clase descendente ale claselog de bază, ele fiind specig/izări ale acestora. 
Ca regulă generală, o clasá derivată moşteneşte toate caracteristicile (starea şi comportamentul) - 
clasei de bază, iar specializarea (diferenţele î în stare sau comportament faţă de clasa de bază) 
poate inscmna: ' 
z = ignorarea unor: caractetistici ale dic. e buză (mai rar întâlnită), ` 
ei E Ze unor noi caracteristici (varia ile de slare sau metode numită speclalizare. 
E S3 > prin îmbogăţire; ` 3; 
- SEH unor. caracteristici alt clasei de bază (în general modificarea unor 

SE adică Specializarea prin inlocuire. qun AE GP A AP 


TZ. 


3 codul M ie întreg. — EE 
Denumire .denumirea. mărfii, sir de caractere : 
„+ unitatea de masura, şir de caractere 
Pret-ach - preţul de achiziţie; numar real. 
TVA. “procent TVA, numar real: 
- Adaos c. procent adaos comercial, număr reali 
Stoc“. cantitatea existentă. în Hoi 
NS E Y număr. întreg . SS EAN ss 3 
EE .. | Metode : (Veo d c e uU i Sa S 2- 


SE SSES rét Arane Pone i. rre rcp E 
Ax E. pe H G Y "ULL ne ach iA Eds 
v d -Pret vi pret vânzare. `- ` 
EE e „Preţ v i= Pref ach (1% CIVAtAdaos vumm GE 

EE EE EE EE 


A Intrareto) intrarea unei Gantitàt t c din marfă 
d “Stoc := Stoc + c 


SC 
lesireto vanzarea. unei cantităţi Ce „de marfă SE în 
S Stoc :- Ste E 3 EA EN S A 


SE E urmare, m jermi ci asa. EE à se: se specilice dod caracteristicile ; 
E noi. Ca DUE generală, dé iei clase. derivate conţine: precizarea părintelui (părinților) gt 


: i taje: A 
recizarea noilor. caracteristici. Acest luc oferă două. prime, avani a) 
p = reutilizarea” definiţiilor; şi a codului caracteristicile, UNOR au EA de la părinți nu mai 


KE webuic i nici specificate, nici codificate; 
s RW definiţii mai simple ale claselor derivate, (se specifică n mai putine elemente), decio mai: 
DAD UD RUE „bună inteleieqe s a specificárii. şi implementării. : 


- j n păi À Sans două tipuri de moştenire: simplă şi i multiplă: Mostenirea simplă corespunde unei 
sigure clase SECH dar mopteniren multiplà presupune Cel pupa doi parnu Kë 


X 


* 


re este o lcgitur intre clase; de la: părinte la. fiu, ce stabileşte o SIN d ; 


Relaţia de mostenii mea claselor. Ín,cazul moştenirii ciment IDA CHA claselor se poate ` 


` pd de piding pe gun 


A 


reprezenta ca un arbore (arborele de mostenire, un nod corespunzánd unei clase), ce are 
rádáciná clasa de bază a ierarhiei, cea mai generală clasă (ce concentrează caracteristicile SE 
ale tuturor claselor din ierarhic), În cazul moştenirii multiple, ierarhia claselor se reprezintă sub 
forma unui graf (graful de moştenire). În arborele (respectiv graful) de moștenire se pot 
considera subarbori (subgrafe), în care rădăcina este clasa de bază a subarborelui (nodul iniţial 
al subgrafului). În cazul moştenirii simple, legătura este de tipul unul (a mai multe (unui părinte 
îi corespund mai mulți descendenţi), iar în cazul moştenirii. multiple, legătura este de tipul 
mai multe ia mai multe (unui părinte îi corespund mai mulți descendenţi, dar un descendent 
poate avea mai mulţi părinți). 

n ierarhia de moştenire, o clasă aflată într-un nod intern sau terminal are două tipuri 
de caracteristici: 


y 


- caracteristici moştenite de la părinți (clasele aflate în aval de ea în ierarhie); 
- caracteristici proprii, specificate în definiţia ei (fie caracteristici noi, fie redefiniri ale 
caracteristicilor părinţilor). i 


Reluând exemplele discutate în paragraful anterior, trebuie să precizăm că schema de 
specificare a unei clase trebuie să conţină, pe lângă elementele preluate de la specificarea TAD 
(nume, câmpuri si metode), şi precizarea părinţilor (superclaselor) clasei în cauză. Prin urmare, 
o schemă completă de specificare a unei clase va avea structura prezentată în figura 4.1.4. 


Fiecare dintre clasele specificate constituie o specializare a superclasei sale, având fie 

„caracteristici noi (Putere abs, Garanţie, - Accize, Tip fire, Capacitate, Standard VCR, 

Țară furnizoare, Provenien(d, Tip írgrediente), De redefinind cáracteristici (metode) ale 
superclaselor (Pret. tr, Pre( v). "enm 


H 


Superclasa . 
Listă de superclase 
Câmpuri 3 R 

specificarea câmpurilor 
Metode ` 


specificarea metodelor 


Y 


Figura 4.1.4. Schema:completá de specificare aunei clase | 


: În figura 4.1.1 este prezentat arborele de moştenire cu rădăcina clasa MARFA. Evident, 
avem de-a face în acest exemplu cu o moştenire simplă, toti descendenţii având o singură super- 
clasă, MARFA. Rămânând in acelaşi context, se pot da exemple rai elaborate. de ierarhii de 

nire. $ SE RS t A i eS 3 
Ee Se La început vom exemplifica moştenirea simplă, considerând trei descendenţi ai clasei 
Du MARFA: ELECTRICE, ARTICOL DE.LUX si ALIMENTE, care vor avea la rândul x 
descendenții FRIGIDER, VIDEO şi HOMAR, respectiy OUA şi BISCUIŢI. Schemele de 
specificare ale acestor clase sunt date în continuare, în figura 4.1.5, iar arborele de moştenire în 


figura 4.1.6. ` 

i Analiză noşțenire din figuri him simplitatea lui (fapt pozitiv) 
Analizând arborele de moştenire din figura 4.1.6, remarcăm simplitatea 

em “pe de o parte, dar şi rigiditatea ierarhiei (fapt negativ), pe de altă parte. Ar părea normal ca 


j 


^. 


112 zm V | ee 


„Clasa 


ELECTRICE ARTICOL DE | LUX ALIMENTE 
Superclasa Superclasa Superclasa 
Peel MARFA MARFA 

mpuri Câmpuri Câmpuri 

Putere_abs Accize Tip 
Metode Metode 


Consum Pret v 2 


Clasa Clasa 
FRIGIDER ' VIDEO 
Superclasa "Superclasa , 
ELECTRICE "ARTICOL DE. LUX ARTICOL DE LUX 
Campuri ^^ |. ` | Câmpuri ~- Campuri ^ — 
Capacitate : Standard VCR Tarà furnízoare 
Metode E |] Metode . ; j Metode ; 


Clasa A Clasa 
: OUĂ ^ | 5] BISCUIŢI” 
; Superclasa - W Superclasa ' : 

ALIMENTE : ALIMENTE. | f Š 
Campuri - d j Câmpuri. ` GEN 

Proveniență Tip_ ingrediente ADEL. o R 
“Metode | ' ; Hetode E d t 

Pret tr 5 ; SE 


SC EE EE 


d Fera 4. 1 6. Arbore cde mostenire 


H 


. VIDEO sá fie Şi deal Ecl ELECTRICE, pentru'cä funcționează c cu curent electi îs 
acest lucru nu este posibil în moştenirea simplă: - 

| Pentru a exemplifica moştenirea multiplă, rămânem în b context, considerând în 
-. plus clasele PERISABILE, FRAGILE si ALTERABILE şi rescriind specificaţiile claselor 
VIDEO, HOMAR şi. OUĂ. Ierarhia de clase a tfel obţinută este mai complexă, i însă relaţiile 
dintre- clase sunt acum mai naturale. Am putut astfel să considerăm cá VIDEO are atât 
caracteristicile unui aparat electric (ELECTRICE), cât şi cele ale unui ARTICOL DE LUX În 
plus, cele trei noi clase introduse asigură o mai bună ierarhizare a mărfurilor: PERISABILE 
(mărfuri care trebuie transportate cu. mijloace de transport adecvate, deci necesită condiţii 
„speciale de manipulare şi transport), FRAGILE (mărfuri ce trebuie manipulate şi transportate 
Cu atenţie, ca să nu se sp uis şi ALTERABILE (care se depreciază rapid in timp), E 
a clasei PERISABILE: În toate aceste situaţii, preţul de transport va xm Som 
suplimentare (datorate fie mijloacelor speciale de deii Nol restricţiilor de S a 
specificarea claselor metoda cu numele Pret tr vai redefinită. oile EE în | 
A 7, Jar s gratus de moştenire în fena 4: 1. 8. 5 


el EE de: Pn 
E DR ` superelasei SC se 
SEN Een şi inspectare 
^ A va corespunde clasei SC; 
eh de la nodul clasei C la: 
- - caracteristica A apar 


„Clasa 
PERISABILE 
Superclasa 
MARFA 
Câmpuri > 
Temperatură , 
Metode 
Pret tr 


> clasg * 
OUA 
Superclasa 
“ALIMENTE 
ALTERABILE 
FRAGILE . 
Campuri 
Rouen lenta 
Metode. ' 


Figura 44.7. SE de clase îi în cazul moştenirii multiple ` 


:Conform noilor specificaţii, clasele ALTERABILE, VIDEO, HOMAR şi OUĂ au mai 
multe Een directe, prin urmare ierarhia ge moştenire s se sia sub forma unui graf. 


GE Fie Co ine Şi A o EE a ei “Dacă A este moştenită, -se pune problenta 
- determinàkii-superclasei SC a lui C pentru care A este caracteristică proprie (SC va fi clasa de la 
cazul fnostenirii imple există un singur drum de la 


care C moşteneşte cáracteristica A). 
data de SE inducând 


pod arborelui. de moştenire la nodul corespunzător clasei C. 


4 


face prin parcurgerea. respectivi 
a fiecărui nod întâlnit. rimul n d în 
În cazul 1 moştenirii multiple, 

al al grafului de moştehir 
um (C moşteneş 
SC se face js E 


nodul inifi 
ține unui singur dr 
singur părinte): determinarea, clasei 
Dee ` moştenirii simple; : 
Ge - caracteristica A, apatoa A 


Clasa 
FRAGILE 

Superclasa 
MARFA 

Câmpuri 


Metode 
Pret tr 


Clasa 
VIDEO 
Superclasa 


ARTICOL DE LUX 


„ELECTRICE ~ 
FRAGILE +. 
Cámpur i 
Standard VCR 
Metode 


+ Clasa 
ALTERABILE 
“Superclasa ` 
MARFA 
PERISABILE 
Câmpuri 
Data_expir 


Clasa 
HOMAR 
Superclasa , 
ARTICOL DE LUX 
- PERISABILE ` 


„Câmpuri 
Tara furnizoare 
Metode” 


^ 


lo existente în nodurile acestui. pde EE 
ug sens invers (de la nodul lui C spre ` 
ese găseşte definiţia caracteristicii 
există mai multe drumuri (în 
e. Pot exista două situații: 
te caracteristica A de la un 
drum, la fel ca in cazul 


a d pu două drumuri (€ mosteneste c zegin 


—— —— 


fuam 


Luet 


WA 1T 9 ATTE gei, 


id wi së wer 


[co 


Ee aa 


la cel puţin doi părinţi), situaţie numită conflict de moștenire; în acest caz 
trebuie (pe baza unei informaţii suplimentare) precizat părintele de la care C 
moşteneşte caracteristica A; între modalităţile de rezolvare a conflictului de 
„moștenire amintim: 

- stabilirea unei ierarhii între părinţi (această ierarhie va dicta ordinea în care se iau în 
considerare drumurile); 

- conflictele sunt de fapt conflicte de nume; se poate încerca o schimbare a numelor sau 

o calificare a lor cu numele clasei părinte (neelegant); 

- moştenirea se specifică explicit, în genul: 


from SC inherits A. 
(dela SC moşteneşte A). 
Revăzând exemplul nostru, un asemenea conflict de moştenire apare în clasa OUĂ, 
pentru care metoda Pre( tr este moştenită atât de la „clasa FRAGILE: cát si de la clasa 


` PERISABILE. În astfel de situații, în schema de specificare a clasei trebuie precizat părintele de 


la care se moşteneşte respectiva caracieristicá. O situaţie analoagă poate să apară si pentru 


„câmpuri. - j AU ; 


: Relaţia de instan(iere este o legătură între obiecte şi clase; obiectul este o instanţă a unei 
singure clase. Prin urmare, această legătură este: de tipul unu /a*unu (de la obiect la clasă). 
Invers, o clasă poate avea: mai multe instanţe. Într-o ierarhie de clase, nu neapărat toate clasele 
pot avea instanţe. Există două categorii de case: Mu es A SS , 
3 - clasele abstracte, ce nu generează instàn(e; de obicei ele sunt în partea superioară a 

ierarhici (clase de bază), conţinând caracteristicile comune ale tuturor claselor, 


descendente; E i ; ss : 
- clasele generatoare de instanţe, ce se află in nodurile interioare sau terminale ale 
ierarhiei. EE SE ` 


3 


+= Revăzând ierarhiile de moştenire ale clasei MARFA prezentate în figurile 411.6 şi 4.1.3, 
putem conchide că MARFA este o clasă abstractă (în cazul moştenirii simple), respectiv că 
MARFA, FRAGILE, PERISABILE şi ALTERABILE sunt clase abstracte (pentru moştenirea 
multiplă). Clasele ELECTRICE, ARTICOL DE_LUX-şi ALIMENTE se pot: considera. fie 


abstracte, fie generatoare de instanţe, pé când FRIGIDER, VIDEO, HOMAR, OUĂ, BISCUIŢI 
- sunt doar clase generatoare de instante. 


SC 
Între clasele abstracte, un loc aparte îl ocupă clasele generice sau clasele parametrizate. 
Dacă moştenirea permite rafinarea caracteristicilor unei mulţimi de obiecte, plecând de la cele 
comune si specializând, obținându-se o ierarhie ín care fiecare clasă are cel puţin o caracteristică 
diferită în raport cu celelalte, genericitatea înseamnă acelaşi comportament pentru clase diferite: . 


„De exemplu, o stivă de întregi, o stivă de şiruri de caractere sau o stivă de înregistrări 
- PERSOANA vor avea (toate) comportamentul generic al stivei.(operaţiile Push, Pop şi Top), 


dictat de disciplina de servire LIFO (Last In First Out). Ceea ce diferă la cele trei exemple de | 
stive este tipul “elementului supus manipulăiii: întreg, sir de caractere, înregistrare. de tip 
PERSOANA. Genericitatea (în acele limbaje în care este implementată) permite parametrizarea 
claselor. Pentru exemplul nostru, va fi suficientă declararea unei clase Stiva[Type] unde Type este 
tipul generic al elementului stivei. Utilizarea acestei clase generice în. cazurile particulare 


nstani(ierea acestei, clase generice: : 


enumerate înseamnă“! 
Suivalnt = new Stiva[Integer]; 
'StivaStr = new Stiva[String]; . 


VA EEUE AE ANINA FCR NA EEN QU 


SuvaPER = new Süva[PERSOANA |; 


Instantele. unci clase 
(clasă = pachet), 
(obiecte). C 


generice sunt văzute diferit în limbaje. diferite. Spre exemplu, în Ada 
)instan(a unui pachet generic este tot un pachet, generator de instanţe terminale 
à $i în cazul moştenirii, genericitatca are ca cfect reutilizarea codului scris. 


3.1.4. Polimorfismul 


: : Într-un program pot exista obiecte diferite, care să fie instante ale unor clase legate între 
cle prin relaţia de moştenire. Le numim obiecte inrudite (polimorfice) deoarece: . > 
- ierarhia claselor ale căror instanţe sunt are o clasă rădăcină, clasa de bază; 
- clasa de bază defineşte protocolul de comunicaţie comun tuturor obiecielor înrudite: 
toate obiectele sunt capabile să răspundă la aceleași mesaje (cum răspund e altă 
problemă, important este că înţeleg aceleaşi mesaje); i 
- sunt de tipuri (instante de clase) diferite. ` e 


à OSEE NOS 3 SE E : 
Stricto sensu, polimorfism înseamnă mai multe forme (aspecte, înfățișări). Termenul este 
împrumutat din biologie, unde se defineşte astfel: variaţie în forma si funcţiile membrilor unor 


specii eu strămoşi comuni în arborele de evoluţie (diversitate morfofiziologicá în același plan sau ` 


în planuri diferite de structură). În terminologia POO, prin polimorfism înţelegeri abilitatea de 
as NOUS ; 


1. pune obiecte înrudite într-un tablou sau colecție; N j 
` 2. utiliza protocolul de comunicație pentru a transmite: mesaje obiectelor individuale, 
„printr-o referire unitară (ca elemente de tablou sau colecţie). 

` În primul exemplu, toate mărfurile ce, se comercializează în supermagazin formează o 
asemenea colecţie de obiecte polimorfice. Ele au în comun același protocol de comunicaţie 
(definit în clasa rădăcină a ierarhiei de moştenire, MARFA), pe deo parte, fiind însă instanţe ale 
“unor clase diferite, pe de altă parte. Spre exemplu, orice marfă se manipulează (se achizifioncazá 
. de la furnizori şi se vinde), deci asupra ei se execută operaţii ca Intrare şi Ieşire şi are un pret 
(determinat cu-metoda Pret v). Pentru operaţiile /ntrare si Ieşire, metodă de calcul este descrisă 
în clasa MARFA (Figura 4.1.3); ca fiind general vălabilă în cazul oricărei mărfi, Nu acelaşi lucru 
se întâmplă în cazul metodei Pret v, care este redefinită în cazul clasei ARTICOL DE LUX, 
deoarece pentru aceste articole se aplică taxe fiscale mai mari, numite Accize. Un exemplu de 

algoritm pentru preţul de vânzare al articolelor de lux ar putea fi: ` Es 


ARTICOL DE. LUX.Pret v: = MARFA-Pre( v Pret ach * Acciz | 100. “~ 


SEINS AE succ D e Ee 
Deci, pentru un articol de lux, pretul de vánzare se va calcula cu formula de mai sus. Prin urmare, 
dacá Hoe marfă M şi dorim să aflăm preţul ci de vânzare, pentru acest exemplu simplificat 
convenţia de apelare ar putea fi: ^ GUESS ; È 

e È ` SCH N A * MPrel v : 3 F $ t | 

d PE S seriile A ARII COL DE LUX.Prat dacă M este articok de lux, respectiv 
unde Preţ v are semnificaţia ARTICOL DE LUX.Pre( v dacă corde Iun 
 MARFA.Pre( v când M este o altă marfă (M va mosteni Pret v de la clasa de bază MARFA). Se 


Z ; AOSE Oa A ar A e aa ai Acucta este un prii exemplu (ma. ` 
remarcă folosirea aceleiași notații, deci simplificarea scrierii. Acesta este un pri; S P : 


simplu) de polimorfism, realizat numai cu ajutorul moştenirii: ` 


O situalie analoagă'este oferită de metoda Pret tr, care este redefinitá în clasa OUA (in 
DE de ? UN jue A DH ` e A Y ; 


> 


eh N E 
A 
D E M Li í 3 


D 


cazul moştenirii simple), respectivin clasele PER ISABILE si j i ip 
nosteniru simple), şi FRAGILE (la moste à 
Ce » DE TR când o Ge, redefinită într-o clasă fiu (cum e Pci) eher 
în clasa de bază? Spre exemplu, revăzând algoritmul de calcul al preţului de vânzar s 
MAREA (para 313) g cul al prețului de v e pentru clasa 


MARFA Preţ_v:= MARFA Preţ_ach + (LU + (MARFA.TVA + 
MARFA.Adaos c) ) 100) + MARFA Preţ tr 


ne puncni întrebarea: cum se va calcula OUĂ. Preţ_w? Răspunsul nu este aşa de simplu cum pare 
la prima vedere. Elementele de calcul ale preţului trebuie să fie caracteristici (câmpuri sau 
metode) ale clasei QUA, deci 


X t 


OUĂ Prep v i= OUĂ Preţ_ach + (1 + (OUA.TVA + 
OUA.Adaos c) / 100) + OU Pret tr 


Dintre acestea, doar Pret treste proprie clasei OUĂ (redcfinità în specificarea4.1.5, la moştenirea 
“simplă, respectiv moştenită de la FRAGILE sau PERISABILE în specificarea4.1.7, la moştenirea 
multiplă). Toate celelalte elemente de calcul sunt proprii clasei MARFA, prin urmare preţul ar 
trebui să se calculeze aștlel: o. 
"OUĂ Pre.» = MAREA Preţ ach + *( MARFA.TVA + 
; rr MARFA Adaos- 0) /4100) + OUA Pret ir 
Suntem deci în situaţia când, pentru a'se obține un rezultat corect, o metodă definită în clasa de 
bază trebuie să apeleze o metodă dinir-6 clasă derivată. Aceasta este a doua faiá a 
polimorfismului, mult mai atractivă, dar mai greu de realizat. Din păcate, numai mostenirca nu 
. este suficientă pentru a punc in practică acest lucru, deoarece, aşa cum am arătat in 4.1.3, relaţia 
„de moştenire este o legătură de la fiu la párinte, deci de la clasa derivată la clasa de bază. Definiţia 
metodei Pre( v fiind făcută în clasa de bază; MARFA, folosind (numai) relația de moştenire se 
va ajunge la 'o definiţie de forma: — See ER 
SE OUĂ. Preţ v:= MARFA Prej ach + (1 + (MARFA. TVA Ios 
0050007 0 st 505 MARFA-4daos c) | 100) + MARFA Pref tr. 
ES EE 
. ^ . pentru OUĂ. Preţ v se deduce (din arborele sau graful de moştenire) că MARFA este 
! Clasa în care Preţ.» este metodă propre: > 


` — 21 Pentru elementele de calcul (Pref ach, TVA, Adaos c; Pre[ 1r) se deducecă toate sunt ` 


proprii clasei MARFA; dacă n-ar fi asa, ele ar fi căutate în ierarhia de 
EE moştenire, în'superelasele clasei MARFA (dacă ar exista asemenea superclase) 


7 E X 


şi nicidecum înapoi, însubclase. 
SS e E z v m ; E uS ie SE S ^ S e DN 
-În concluzie, putem rezumă caracteristicile polimorfismului astfel: ză 


“1. Polimarfismul necesilă moştenire. Fără moştenire nu am avea o clasă de bază, deci nu 
^ ar exista protocolul comun de comunicaţie; 3 
-2. Mostenifea, nu. este suficienta pentru realizârea poli t d 
mecanisme suplimentare. În cele ce urmează vom discuta modul în care 
interacționează aceste două mecanisme şi de ce mecanisme noi mai e ENER 
3. Polimorfismul simplificà munca programatorului, uniformizând sintaxa mesajelor şi 
= miicgoránd complexitatea programelor. — - A st Seat : 
Á [4 RUIN i P" CS K : S A P 


x 


liniorfismului, find nevoie de - 


„Diferenţele dintre polimorfism şi moştenire le 
scop, arie de cuprindere şi efecte. Moșteni 
în ideea unei mai bune structurări a uni 
polimorfismul simplifică comunicarea c 


putem discuta în raport cu trei aspecte: 


versului obiectelor, prin eliminarea redundantelor, iar 
u'sau între obiectele înrudite. Din punctul de vedere al 
oate caracteristicile claselor (câmpuri şi metode), pe când 
ele:ce definesc protocolul de comunicaţie (de fapt numai 
rmează, vezi 4.1.5). Moștenirea are ca efect reutilizarea 
estar orfismului; polimorfismul utilizează mostenirea pentru a 
puri polimorfice, ce au ín comun acelaşi protocol de comunicaţie, definit în 


ariei de cuprindere,moștenirea implică 
polimorfismul are ca obiect doar metod 
metodele virtuale, definite în cele ce u 
codului si permite manifestarea polim 
construi ierarhii de ti 
clasa de bază. 


4.1.5. Consideraţii de specificare şi implementare à POO 
4.1.5.1. Clasa ca tip abstract de date 


În secțiunile anterioare, am asimilat o clasă de obiecte cu ua TAD, Faţă de schema 
generală de specificare a unui TAD, trebuie considerate noi aspecte, legate de: 
ze - specificarea mostenirii; ; 

- regulile noi de vizibilitate si acces induse de moștenire 

`- specificarea operațiilor (metodelor). ` 


3 
$ Specificarea moştenirii apare la definirea unei subclase, când trebuiesc făcute precizări 
privind: A iii Pot 
S -:parintele (în moştenirea simplă); e 
- părinţii si ierarhizarea lor (în moștenirea multiplă)... : 
Regulile de vizibilitate şi drepturile de acces s-au rafinat, În funcţie de vizibilitatea lor în 
exterior, caracteristicile unei clase se grupează în (exemplu: limbajul CE zk 
“= publice (se:pot accesa şi/sau modifica în exterior); 3 ; ; 
- private (nu se pot accesa şi/sau modifica în exterior); = 
~ protejate (se pot accesa şi/sau modifica doar în subclase).' 


5 În plus, la specificarea moştenirii se pot prevedea modificatoride acces ai caracteristicilor 
'claselor părinţi: f : : RENDUM : i perc. 
E S 3 public: păstrează aceleaşi drepturi de- acces pentru descendenți la caracteristicile 
ne) S i 9mostenite;: Ce a Som : m 2 

- privat: interzice accesul pentru descendenţi la caracteristicile moştenite. a 


là sfârşit, 0, altă modalitate de acces este oferită de clasele prietene (friend în limba 
'engleză). Dacă o clasă C este prietenă a unei clase ©’, atunci C và avea acces la câmpurile private 
“ale clasei €. +2: ua CER ice RS aa SE 


POO, unele operații capătă noi valențe (constructorii şi destructorii) ŞI apare e altă ee : 
*- operaţiilor, după critertul momentului legárii (metode statice şi virtuale). În paragr 
-*. yom detalia noile aspecte menţionate. <" ik 


^ 


UPS ; T i 5 T K ' v D Y Y WI 


irca are ca scopierarhizarea claselor (tipurilor de date),"- 


“La TAD am discutat tipurile de;operaţii după funcţionalitatea lor. În cazul claselor din. « 


H 


TT 


x 


4.1.5.2. Glasa în POO 


Constructori şi destructori 


D CS I = en i ` mifni tos ` d j d ta 
În POO, constructorii sunt specifici claselor, În ufara funcțiilor cunoscute deja de | 
Ls dea bazată pe obiecte (creare de obiecte, cu iniţializarea unor variabile de stare), în 
true egal i alta f THE Wen i a" clasei ? 1 i Meet! 
constructorii au şi o altă funcţie: pun "semnütura" clasei în iert, Practic, ne putem imagina 


acest lucru în felul următor; un obiect O al unei clase C va fi o variabilă ce va confine: 
- spaţiu pentru variabilele de stare (in conformitate cu definitia clasei C); 


- o legüturá spre clasa C (un pointer, de exemplu), ce reprezintă materializarea relației 


de instanţiere, 


Avem 0 primă regulă: 


R1. Orice obiect O al unei clase C se construieşte prin qpelul unui constructor. 


(Dacă regula R1 ar fi încălcată, ar putea exista obiecte'care să nu-şi recunoască prototipul). 


D 


Informaţia de instânţiere este utilă la excouţie, când cu ajutorul ei se poate determina 
exaci clasă instanţei (obiectului). Această regulă este valabilă în cazul programării orientate pe 
obiecte. În programarea bazată: pe obiecte‘ nu este necesară, existen[a constructorilor în 


| "accepțiunea de mai sus. ` 
; d 


de instan(iere. 


, 


Legare statică şi dinamică 


codul, ea fiind proprie implementării modulului. 
À X 


deșfăşoară la momente diferite de tim 
"codului rezultat în urma compilării). In sc in inter d à 
principial una dupá alta pentru fiecare linic sursă (întâi traducere, apoi execuţie): 


sensul că, într-o fază oarecare a traducerii, compilatorul poate asocia re 
adresa unei variabile (când avem un nume do variabilă) sau adresa punctu 
subprogram (când avem un apel de procedură sau de funcţit 
identificator precede referirea,lui, 


Analog, un destructor (în alara funcţiilor deja cunoscute) trebuie să distrugă si informaţia 


Limbajele de programare folosesc din plin noţiunea de identificator. Prin identificatori, 
„programatorul face notații (între altele) pentru variabile si subprograme. Un identificator poate, 
fi văzut în două momente distincte: declararea şi referirea. În general, o declarare a unei variabile 
se face printr-o instrucţiune dc declarare de tip, iar declararea unui subprogram respectă cerinţele 
sintactice ale fiecărui limbaj în parte: se specifică de obicei tipul subprogramului (procedură sau 
funcţie, la última şi tipul rezultatului obținut) si lista parametrilor formali (nume si tip). Începând 
cu abstractizarea datelor, putem vorbi atât de declararea unui subprogram (văzut ca o operaţie 
a unui TAD), cát si de definirea acestüia. Declararea se face în partea publică a modulului 
(interfaţa acestuia) şi în unele limbaje nu specifică decât tipul părametrilor; definirea precizează 


„Prin legáre înţelegem o operaţie ce are loc într-un program traducátor (compilator sau 
interpretor), ce constă în înlocuirea referirii unui identificator (nume "de variabilă sau de 
procedură ce apare în textul sursă) printr-o adresă (din codul programului, rezultat în urma 
traducerii). În cazul compilatoarelor, fazele de compilare și execuţie ale aceluiași program se 
(întâi compilarea integraláa textului sursă şi apoi execuţia 
n schimb, în interpretoare aceste două faze se desfăşoară 


1 În limbajele de programare dotate cu compilatoare, spunem că legarea este statică, în 

feririi unui nume o adresă: 
lui de intrare a unui 
1. Cum de obicei declararea unui 
declararea are ca cfect fie alocarea de spaţiu in cod (pentru 


: 
ih in taba n PE de cod (pentru sub para) în ambele cazuri memorándu-se (să zicem : 
m a de simboluri) corespondenţa nume-adresă (de variabilă sau de punct de intrare). Şi 
i si mai exac|i, ceca ce nu poate rezolva compilatorul (în cazul cómpilárii separate a 
p arate or) a ee o, de legături, principiul rămânând acelaşi. 
n cazul limbajelor puternic tipizate, în momentul 
popă tate, p legării se mai fac si alte verificări de 
- a tipurilor (pentru variabile); ` 
-a listelor de parametri actuali (pentru apelurile de subprograme). 
} 
; În limbajele de programare dotate cu interpretoage, spunem că legarea este dinamică, 
ea având loc în momentul HE 


i Fiecare Jare tipurile de legare discutate precint avantaje ŞI decavantaje; pe care nu le 
discutăm aici. — 
shnpiementarea polimorfismului SPA i 
Am văzul că; polimorfismul presupune tratarea: bnitará-a a obiectelor înrudite, ce au în 
comun același protocol de comunicaţie, definit de clasa de bază. În fapt, protocolul de comunicaţie 
“înseamnă o listă- de identificatori- (nume de metode definite în clasa de bază). Am văzut de 
asemenea că obicctele înrudite nu au. Comportament identic, deci un acelaşi identificator de 
- “metodă poate să refere EE semantic! diferite (deci acţiuni suere) pentru două obiccte din 

` clase diferite. ra So e er uM ate ge CURE 


Manipularea SE polimorfice i inscamnà parcurgerea EE De 
"1. Se declară o colecţie (listă, tablou). de NDA în care un element al colecţiei are tipul > 
clasei de bază, - - : 
2: Se creeaza şi se introduc ín cce biet de aporia EE ale clasei: de bază - 
E BI (colecţiă va fi héterogená); crearea de obiecte se va face apelând constructorii 
Se - proprii claselor respective, carc vor pune semnătura clasei în instanţe; 
a "Een | Se este că oale, Gu SE se. pot trata unitar in 


PIG ` under | 


EC (zccéptorul) este. pe aa al coleeiiei 
SA S Se S (selectorul numele metodei) aparţine, protocolului da comunicati dofini de 
Zt pex acR de qupe net clasa de bază. Rep 


| Consideram cá à discutăm despre u un n limbaj dotat cù compilator. Se pung ne întrebarea: ` 


i ze poate folosi Jegarea statică peniru implementarea polimorfi ismului? -` 


D 


| “Raspunsul este UN NU CATEGORIC! sa vedem de ce. us 


rece) torului EC, ci dar clasa de bază a lui, 
` Ar fi bine doar, dacă clasa EC 


AOE AE La compilare. hu e cunoaşte Exact clas 
pum Së pe baza irstrucjiunii de declarare a colecției.. S 
- -. * coineide cu clasa de bază; . 
^ 2, Mesajul de mai sus pe e printr-un apel al nictodei S; la compilare se va alege în: 


toate cazurile (indiferent'că cáréi depar apartin EC) pie od Sa clasei dè bază. 


* 
Din nou ar fi bine doar dacă clasa EC coincide cu clasa de b 
corespunzătoare clasei EC ar fi moştenită din clasa de Mem dq. E 
3. Ca să se aleagă metoda adecvată clasei lui EC, ar trebui să se cunoască clasa lui EC 
„deci compilatorul ar trebui să aibă acces la reprezentarea obiectului EC (unde 
se găsește şi "semnătura" clasei, pusă de constructor). Indiferent dacă EC este 
un obiect static sau dinamic, el va exista numai după apelul constructorului, care 
apel înseamnă o acţiune efectuată /a execuția programului, şi nu la compilare. 
` . Chiar dacă la compilare avem acces la reprezentarea obiectului (când acesta 
este alocat în segmentul de date; n-am avea acces dacă este alocat în stivă sau 
în heap), informaţia de instanfiere nu este completată, deci nu se poate deduce 

i .. clasa obiectului; d 
4. Cum se poate face distincţie între metode care se leagă static şi cele care se leagă 
` dinamic? La această întrebare nu putem încă răspunde, dar trebuie să avem în 


1 


vedere o atare situație. 


Din discuţia de mai sus rezultă că (pentru compilatoare): | 
. - polimorfismul se poate implementa numai prin legare dinamică; — ^. . 
- protocolul-de comunicaţie trebuie să precizeze şi tipul legárii (legare statică sau legare 
dinamică). SN dee RIS. BLAN 


Metode statice si virtuale DOS ESS 


Am văzut că pentru o colecție de obiecte polimorfice, clasa de bază definește protocolul 
de comunicaţie. În același timp, am:constatat că nu este suficientă definirea metodelor comune, 
compilatorul trebuind să cunoască şi tipul legării pentru fiecare dintre metodele ce formează 
protocolul de comunicaţie (celelalte metode se vor lega static). . ` 


`` Acesta este ultimul impediment în implementarea polimorfismului şi el se rezolvă prin ` 


. " aşa-numitele metode virtuale. Termenul de procedură virtuală este introdus pentru prima dată 


în Simula67, fiind preluat între altele de C+ + (funcţie virtuală) şi Turbo Pascal (metodă 
virtuală). Avem, prin urmare, încă un criteriu de clasificare a metodelor unei clase, după 
momentul legárii lor: ` CQ cR SA Ec e CRESE aa cea 

- metode statice (legare statică, la compilare); . .  » 

' - metode virtuale (legare dinamică, la execuţie). SE x zr 

Cu aceste precizări, putem defini mai exact protocolul de comunicaţie, ca fiind format din 
metodele virtuale ale clasei de bază. S ; EE d 

Proiectarea protocolului de comunicaţie trebuie să respecte regulile: 


R2. Constructorii nu pot fi metode. virtuale; AS eR SBR EE ES 
(ei sunt responsabili cu "identitatea" obiectelor, deci trebuie legaţi static); ` 
R3. Destructorii pot fi metode virtuale; — T META a 
R4. Dacă o metodă V este declarată virtuală într-o clasă C, toate redefinirile ei din descendenţii lui - , 
c C vor fi virtuali a p RUN ei SIR POLEN : SECUN 
R5. Specificarea metodelor virtuale proprii trebuie să corespundă celei din clasa de bază, pentru ` 


SN > orice clasă descendentă a clasei de bază, 


' -. < (optional, là limbajele puternic tipizate, « ánd compilatorul verifică lista parametrilor + 
fa actuali) GE 2 d EE Se X | d 
R6. O clasá ce are metode virtuale trebuie să posede cel putin un (constructo 


D 


D 


m 


Obiectele la muncă | 000 00 90 N row 
Triada constructor - metodă virtuală - legare dinamică asigură implementarea corectă 


w 


S 
* 
et B ` Y * 


x 


a polimorfisenului, În linii geniis 
convenții: - 


această implementare presupune următoarele etape şi 


IA teii H LN fiecare clasă ce posedă mitade virtuale, compilatorul construiește tabela de 

metode virtuale (Virtual Method Table VMT î in Turbo Pascal, Virtual mm ; 

. Table VFT în Borland C + +), ce conține pointeri la punctele de intrare ale - 
acestora (perechi de forma nume _metodă, adresă punct de intrare); ` 

2. Semnătura clasei, pe care constructorul o pune în fiecare obiect este de fapt un pointer 
` la tabela de metode virtuale a clasei obiectului; : 

3. Ín cazul legării dinamice, obiectul este cel care oferă informaţia necesară legării, în el 
existând referința la tabela de metode virtuale ce trebuie consultată pentru a se 
rezolva apelul. 

4. Metodele sunt considerate. implicit statice; declararea ui unei metode virtuale se face 
explicit. SC 

3 Revenind la mesajul: ; 

R sena(R SLAD 
rezolvarea lui se poate discuta în două ipostaze: 

SN - S este A nume: de Mo ana 


vetet ER i ! MU x 


VA. mmm Se GE EE A a P 


E N 
- Legarea staticá se realizează când S. esteo metodă statică, Toate opea Te mai jos se 
: execută la compilare: ` : A 
rai Paza dă ae 3B se determina clasa C a lur R (din declararea hu. S Qe e 
E me „2. se verifică dacă S este o metodă a clasei C (pr m 


ss 138. Dacá NU, se va genera un mesaj de eroare (eroare de sintaxá) z i 
EE E Dach DA, se venha lista parametrilor. actuali cu declararea metodei (dacă există o: 
ee ~ listă de netri uali şi dacă limbajul este puternic: tipizat); ` : 
ce statică Cu se traduce prin salt la punctul de 


Observație | 3 2 SEH SEN $ oc : De SE E mu E ce 


« d SN 


fo diferá prinlista 
= * "Unelelimbaje (C+ + audi) SE SE proceduri cu acelaşi nume, ca care 
pam GEHT Lo sunt supraincarcate). n ullor, trebuie utáo Verificare in plus metoda 


LC o seste identificată după! nume e SC Au argum nt 


` 


E m decns 


„Ec. GE un o al unei Kë rent S 
s este ER metodă oda viri 3 


g e 
Acţiunile se desfăşoară în două momente distincte: compilare şi execuţie, 


La compilare: 
x se oam C - clasa de bază a elementelor colecției EC; 
se verifică dacă S este o metodă (Virtuală a lui C, identificându- nctul de intrare 
in VMT 5 SS e ) u-se punctul de intrare 
3. Dacá DA, se verificá sintaxa apelului, 


4. Dacă sintaxa apelului este corectă, se pune în cod adresa relativă a metodei $ din 
VMT a lui C. 


La execuție: 
© «1. se determină C - clasă efectivă a EC (din EC avem adresa VMT; de fapt se identifică 
WMT a clasei efective, din semňátura pusă în obiectul EC de constructor); 
2. se identifică S în VMT determinatà la pasul anterior (1), pe baza adresei relative a lui 
S din VMT, determinată la compilare; 
3. din VMT se ia punctul de intrare determinat la pasul 2 și se continuă la fel ca la 
legarea statică. 4 
s In explicațiile;de mai sus, am. Gonsidelar cá, deoarece GE de bază este cea care defineşte 
protocolul de comunicaţie (prin metodele sale virtuale), în tabelele de metode virtuale ale claselor 
derivate o metodă virtuală $ va ocupa aceeaşi locaţie (va avea aceeasi adresă relativă a unui nume 
de metodă în toate VMT ale unei ierarhii de clase). Prin urmare, la compilare se va determina 
locaţia din tabelă (adresa relativă) corespunzătoare metodei virtuale apelate, i iar la execuţie se va 
determina î în care tabelă de metode RUD se face cáutarea. j 


Revenind la exemplul discutat în, Lt 4, putem. spune acum că pentru: ase obţine un calcul 
corect al prețului de vânzare pentru c sat UA metoda Pret tr trebuie declarată virtuală, iar clasa 
- OUĂ trebuie să-aibă un constructor specific (analog clasele FRAGILE şi PERISABILE în cazul 
moştenirii multiple). -În aceste condiţii, legarea metodei Pret tr'sc Va face dinamic, căutarea 
metodei virtuale în arborele sau graful de moştenire începând din clasa OUĂ. Se observă încă - 
odată utilizarea moştenirii, deosebirea (față de legarea statică) fiind că această căutare are loc şi | 
în adâncime (fiecare căutare începe din clasa obiectului și nu din GE în care apare perm t 
dată referirea dă caracteristica cautati i in cazul nostru Preţ A : 


e 


* 4. 1 6. Pagi DE POO. 


Bertrand Meyer [Mey88] e Ges pe care tebie să. le indeplincascá un ` 
produs program şi limbaj de programare orientat pe obiecte. În afara primei cerințe, care dă 


P - criteriul de proiectare, toate celelalie ; se referă la! programare, în sensul rum al termenului: 


Primul- el corespunde observajici: datele trebuie: să ofere d ee de 


sinicpurare: H: i EE ODE 
e Nivelul 1 1 (Structură modulară bazată pe. ent E KS s 
jar f “Sistemele surit modulrzate pe < sin de date proprii! 


Proiectarea programelor are dent criteri datele RAE $i nu fedia care, re programele Se 
7 trebuie să le realizeze. Ao" 23 | - d 


Dën 


Următorul fer realizează conectarea cu TAD: 


M "Lat TA , 


RE 


E: 


Ska 


GE 


E 


EE 


Nivelul 2 (Abstractizarea datelor) " 


Obiectele trebuie descrise ca implementări ale TAD. 


ER Al treilea pas este de natură mai puţin conceptuală si mai mult practică, reflectând o 
cerinţă importantă de implementare: cum se creează obiectele. Programatorii nu trebuie să se ! 
preocupe de alocarea sau dealocarea memoriei pentru obiecte: | 


Nivelul 3 (Gestiunea automată a memoriei) 


Obiectele neutilizate trebuie dealocate de sistemul de bază (substrat) al limbajului, | 
fără intervenţia programatorului. 


. . Următorul pas este cel care face o separare clară a limbajelor bazate pe obiecte de restul 
lumii. Sé poate spune că ecuaţia de definire a acestor limbaje este identitatea: 


l 


clasă = tip de date. 
Nivelul 4 (Clase) S : ' | 


Orice tip de date non-simplu este un modul şi orice modul de nivel înalt este un fip de date. 


Calificatorul "non-simplu" face posibilă păstrarea tipurilor de date predefinite, care nu sunt văzute 
ca: module; cuvântul "nivel înalt” permite; existenţă” unităţilor de structurare a unui program 
(procedurile) care nu sunt tipuri. 


» 7 
“Următorul pas este o consecință naturală a celui precedent: dacă tipurile de date se 
identifică cu modulele, suntem tentaţi să identificăm mecanismele de reutilizare oferite de ambele 
concepte; 7 E 
j - pe de o parte, posibilitatea unui modul de a referi direct entități definite în alt modul; 
= pe de altă parte, conceptul de subtip, prin care se poate defini un nou tip adăugând 
proprietăţi noi unui tip existent (ca un subdomeniu Integer din Pascal, subtip al 
lui Integer cu precizarea limitei inferioare şi superioare a domeniului său). 


> 


D 


Nivelul 5 (Moștenire)! 


J "XI Y z R 
O clasă poate fi definită ca extensie sau restricţie a alteia. 
7 . 


Tehnicile de mai sus deschid posibilitatea folosirii polimorfismului si legárii dinamice: 


Nivelul 6 (Polimorfism și legare dinamică) . | ` 
Entităţile unui program trebuie:să poată să fere obiecte din mai multe clase, iar operaţiile 
^^ webuie să aibă realizări diferite în clase diferite. AN : 
Următorul gi ultimul pas extinde noţiunea de moştenire pentru à permite reutilizarea în 
mai multe contexte. Aceasta înseamnă moştenirea multiplă. LIE" 


Nivelul 7 (Mostenirea multiplă şi repetată) 


N 


Trebuie sg se poată declara clase care să moştenească de la mai mulţi părinți şi/sau de mai 
$ | ` | : 
multe ori de lu aceeaşi clasă. 


124 
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42. PROGRAMARE ORIENTATĂ PE OBIECTE ÎN TURBO PASCAL 


73 


4.2.1. Clase şi obiecte în Turbo Pascal. Terminologie 
V I 

Turbo Pascal este în acelaşi timp un mediu și un limbaj de programare puternic tipizat, 
ce posedă o extensie POO începând de la versiunea 5.5. Fiind un mediu de programare 
binecunoscut utilizatorilor de PC-uri, Turbo Pascal este accesibil incepátorilor şi capabil să ofere 
suficiente instrumente pentru realizarea de aplicaţii profesionale. În plus, există un mare număr, 
de cărți şi articole de specialitate legate de el. Deoarece limbajul Pascal este folosit pe scară largă 
în procesul de învăţare. a programării calculatoarelor (în școli şi universităţi), Turbo Pascal 
cunoaşte o mare popularitate în mediile academice, fiind, prin extensia POO, un mijloc relativ facil 
de familiarizare cuconceptele programării orientate pe obiecte. Din punctul de vedere conceptual, 


extensia POO din Turbo Pascal se inspiră din limbajele C + + şi Object Pascal. 


- La prima vedere, ar putea apare o confuzie în notații. În TP, o clasă este de tipul 
predefinit object şi se defineşte (în versiunea 5.5) cu ajutorul mecanismului type (propriu 
limbajului Pascal), în forma: à e 


type nume. clasă. = object|(nume_superclasă)] 
declaraţii de câmpuri 
specificări de metode 

end; 


Conceptual, o clasă este tratată ca un tip virtual de date, pentru ea fiind definite 

câmpurile (ce formează domeniul T VD) si operatiile (metodele). Definiţia de mai sus corespunde 
părţii de interfaţă a unui TVD, ca trebuind completată cu partea de implementare a metodelor. 
La implementare, antetul unei metode este calificat cu numele clasei:: E 


procedure nume clasàume metodá|(parametri formali)]; 
e i EN 
sau : 
function nume clasázuume- metodá[(parametri formali) : tip; 
Instanţele unei clase, numite- obiecte, sunt declarate ca variabile de tip nume_clasă: 


var ob1,0b2 : nume clasá; x 


Declaraţia de mai. sus corespunde unor obiecte statice (alocate în segmentul de date sau în stiva” 
de execuţie). Folosind: pointerii, se poate lucra şi cu obiecte dinamice, alocate în heap: 


type pointer nume clasă = ^ nume clasà; 
var pobl,pob2 : pointer nume clasá; S 


„Apelul unei metode se face printr-un mesaj de forma: 


ob1.mume_metodă(listă_de _parametri_actuali); EE d 
sau 


pobl^ nume. metodă (listá de ` parametri actuali);' 


în care ob1 (respectiv pobl ^) este receptorul, iar numele metodei este selectorul. 


H LANI * : D 
Prin definiția unei clase nume_ clasă se specifică şi interfaţă clasei respective cu mediul 
extern. Regulile de vizibilitate permit ca atât câmpurile cât si metodele să fie vizibile (deci 
utilizabile) în exterior, Dacă pentru metode acest lucru este normal, accesul din exterior la 
câmpuri (inclusiv posibilitatea. modificării valorii lor) încalcă una din regulile de 'bază ale 
abstractizării datelor: modificarea valorii câmpurilor unui obiect trebuie să se facă numai prin 
operaţiile proprii obiectului respectiv. Pentru înlăturarea acestui neajuns, în versiunea 6 a 
limbajului Turbo Pascal există posibilitatea declarării de metode şi câripuri private, ce sunt 
invizibile în exterior. Câmpurile private pot fi referite, numai în partea de implementare a 
metodelor (publice sau private) ale obiectului; iar metodele private servesc la implementarea 
„celor publice. Schema de definire a unei clase de obiecte în Turbo Pascal 6:0 este : 
. type nume clasă = object[(nume. superclasa)] 
declaraţii de câmpuri publice : 
' specificári de metode publice 
private ` A 
declaraţii de câmpuri private +; 
specificări de metode private- i 
end; es SE SC 


„Pentru protejarea eficientă a câmpurilor unui obiect, se recomandă ca ele să fie declarate 

-în zona private. Dezavantajul acestei metode de proiectare a claselor de obiecte constă în aceea 

* că utilizatorul nu va avea acces la aceste câmpuri, nici măcar pentru a citi valoarea lor. Acest 
impediment poate fi surmontat prin adăugarea: de metode publice, care să furnizeze valoarea 

- acestor câmpuri private. În acest fel, câmpurile devin accesibile în citire (read only), dar valoarea: 
lor nu se va putea modifica decât prin metode. În specificarea 4.2.1 este definită clasa Locaţie, cu 
"următoarele atribute: sie pat al : 


v * 


(private): 


câmpuri XV eL PES S INA private) 
metode: Init: - modifica câmpurile X şi. Y ale obiectului 
: GRON la valorile specificate prin àX şi aY} 
i Xcoord 4 $0 s *Cântoaree valoarea abscisei XL 
SE soo o Ycoord — — > . {întoarce valoarea ordonatei Y. S > 
: EE E ` Type y EH - zr ` S HS s CS is iT 2 
r Locate: = Obiecte EE 
4. procedurelnit(aX,aY:Integer. oe 


function XCoord : Integer o 5 0 9) ae a A 
function YCoord : Integer; i 


SC pale. )- o a due | i e 
EE E Integer; a EA E AUS at ada m 
P E Specificarea 4.2.1. Câmpuri private şi metode publice - ; 
Metodele publice XCoord si YCoord au fost concepute tocmai pentru a permite mediului Nem 
să cunoască valoarea coordonatelor obiectulu Sie NOS EE SENSE 


D te > 


1 4.2.2. Mostenire. Obiecte statice 


B Turbo Pascal moştenirea este 

simplă. Prin moştenire, câmpurile supe 
seo şi nu pot fi redefinite. În schimb, metodele unei superclasé se pipa in 
conformitate cu comportamentul specific al subclasei căreia le aparţin. În specificarea 4.2.2, se 
consideră clasa Punct, descendentă a clasei Locaţie definită anterior. Obiectul geometric punct 


da plan) posedă două coordonate și un atribut de vizibilitate: el poate fi desenat (este vizibil) sau 


` ype ` à 3 
N “Punct = Object(Locaţie) >= ~ 7 $ ; ; 
3 procedure Init(aX,aY: Integer) ` VAMOS D | 
=` procedure Desenează; Y Men 
; . ` procedure Ascunde; XQ EIU A EDO 
A function EVizibil:Boolean;: 3055005 1008 amp 
S procedure Mutüln(nouX, Gonscht SE 
procedure Translateazá(pas:Integer); - up DNE UM COT. 
S procedure Roteşte(centru:Locaţie; voei Teen de eue 
function Caracteristici: Siring, t 
: procedure Listează; ` GE S 
private ^ . IASON EM 5 
Vizibil : mox ASA Zara OS ELS ANN 


D 


campuri: HY „private: şi, moştenite de. la Locaţie) | - 


7 Vizibil - | (privat). n z 
; netode: Init AXES {redefineste m metoda indi de: la Locaţie. 4 
US : SE în plus câmpul Vizibil)- 
e : XCoord, . YCoord m (moştenite. de la Locaţie) S 
Desenează > Tusc (desenarea. obiectului pe ecran) SE SS 
Eau Ascunde. ^. - (ştergerea obiectului de. pe. ecran) RUE, vx 
-fEMVZibil == _Cîntoarce valoarea campului vizibil |. 
Dx sMutafn. ^. Sd calita obiectul în Locaţia Dou. 'nouY) 
j Translatează | (efectuează o translație, mărind. x 
EN 5 i Vata le. coordonatelor” cu. valoarea pas): iz d : 
SC Roteşte La Se obiectul in jurul locației 5 ` 
S ed 27s, v eentrü, cu unghiul unghiX |. S ` a 
Caracteristici ^ {intoarce un Şir, de. caractere ce | ~ SE E 


= ^*eontine, valorile coordonatelor. 
SE caracterist ite oec 


S Li stează! 


d e fă această SE metoda. dE a re Punct! Sie metoda Q omonimă de la superclasa 


dg Locaţie, concretizând comportamentul specific a al SE iar. metodi Evizibil permite. 
EE valorii câmpului Vizibil i în mediul extern. CE s 
uUo. Di du odi atena A de es Ponce EE 
2 . corespunzătoare clasei Cerc, descendentăa clasei Punct. Conceptual, obiectul geometric. cercare 
„| ca invariant un obiect geometric punct, numit centrul cercului, prin urmare moştenirea este 
E naturală. În afara SE cercul See o Hu d dud Zeie clasei Cere sunt - 


Dues du A , PARUM OHNE pd, ate e RENS 


AD 


` 


* 


câmpuri :- X,Y, Vizibil 


(private şi moştenite'de la Punct) 


pas e i (raza, privat) 
metode: Init ed A metoda Init de o Punct 


înițializează în plus câmpul R} 

»XCoord (moștenită de la Lokatie} 

YCoord (moștenită, de La Locaţie) 

EVizibil „(moştenită de la Punct) 

Listează (moştenită de La Punct) 

Desenează „ trasarea obiectului pe ecran 

; Fedefineste.metoda omonimă de la Punct) 

Ascunde (ştergerea obiectului de pe ecran 
3 . _ redefineşte metoda omonimă de la Punct} |. 

Mutăîn „mută obiectul în Locația definită 


B de coordonatele nouX, nouY , 

: redefineste metoda omonimă de la Punct) 
Translatează (efectueaza o:translatie, mărind 
: : valori le! coordonatelor cu pas 
redefineste metoda omonimă de la Punct} 


*. Roteste rotește obiectul în jurul locației - 
: „>. "centru; cu unghiul unghi : 
redefineşte metoda omonimă de La Punct} 
Măreşte. ` EE (măreşte raza. cercului. cu 
OUR N "valoarea parametrului pas) 
Raza MS .— (întoarce valoarea: câmpului. R} 
„Caracteristici (întoarce un şir de caractere ce 
IS ceata contine valorile coordonatelor si razei) 


„redefineşte metoda omonimă de la Punct) 

: — . Metoda Raza permite cunoaşterea valorii razei cercului in mediul'extern. Metodele Init, 
Desenează; Ascunde, Mutáín, Roteşte $i Translateaz sunt redefiniri ale metodelor omonime ale 
- superclasei Punct, ele concretizând comportamentul specific al clasei Cerc, diferit de cel al 
părintelui sáu Punct. Astfel, desenarea unui cercînseamnă desenarea centrului şi a circumferinței; 

. analog ştergerea. Mutarea unui cerc (de fapt mutarea centrului său) presupune ştergerea vechii 


imagini, mutarea centrului şi desenarea noii imagini a obiectului. În mod analog se procedează _ 


şi în cazul translaţiei sau rotației obiectului Cerc. Acest lucru va rezulta cu exactitate din 
implementarea claselor Locaţie, Punct şi Cerc, care este dată în continuare. Se observă gradul 


. - ridicat de simplitate al algoritmilor folosiţi. — - 


Type us) I M RSEN EN cala MIR a e S 
EE 
procedure Init(aX,aY,aRaza:Integer); VEA E 
-procedure Deseneazá; = i SEN à 


procedure Ascunde; 


. procedure Mutáln(nouX,nouY;Integer; `" 
^ procedure Translatează(pas:Integer); Rr QU DN Re LUN S 
. procedure Roteste(centru:Locafie; "unghilnteger) ^. Si 

procedu e Máreste(CuCit:Integer oe : 

function Raza: Integer; ^... 

function Caracteristici : String; 


m DEN 
PNA see pis AN ONEA EC 
EE ; SE 
EE 2i 2 


AN 1 UN Pe e « 
4 Ma A j AR Sie Y ep SN E DENN E. vw N 


Specificarea 4.2.3. Rafinarea moştenirii 


Exemplul 4.2.1. Implementarea metodelor clasei Locaţie 


procedure Locafie.Init(aX,aY:Integer); 
Begin 
Kies aX; 
Oe E 
“End; { Init } i si 
function Locatie.XCoord : bere 


3 Coord:= X 

a End; ( XCoord] ` 

a function Locaţie. Meet: : Integer; i SÉ = 
3 ~ Begin. : 

a YCoord:= Y - Ea e aL INDE E CHER 

a Fei (YCoord } | GE EE SS 


NS es cS sli 4. 22. 2 Implementarea metodelor. clasei Punct 


f rodit Punct. Deen 


- Begin 
Vizibil : = = True; - SC 


End; ( Desenează ) ` 
^ procedure Punct Ascunde; 


„ function Punct EVizibil : “Boolean; 

-Begin = 
EVizibil :— = Vizibil 
End; ( EVizibil ) : 

. . procedure Punct. Multam 
Eg. x 
EECH EE 

- Deseneazá. : S EE 
' End; ( Mutăln) — iQ RE Sa T 
REIR miei Rod ES ere 
2 S , a : à : 3 a Eck? P 7 
` CnXCnY: irc ac E a apa ap educ E NA RR 


e 


120: 


. Exemplul 4.2.2. Implementarea metodelor clasei Punct (continuare) 


Begin 
Desenează; 
CrtX := XCoord; . 
CrtY := YCoord; 
While CeDirectie(DX,DY) HE 
„Begin 
CrtX := CrtX + DX * pas; 
CrtY := CrtY + DY * pas; 
MutăÎn(CrtX,CrtY) 
End; 
End; ( "Translateazá ) 
procedure Punct.Roteşte(centru:Locaţie; E SE 
Var nXny: Integer, 


Begin 
nx := XCoord; - 
ny:- YCoord; 


 RotegePunc(nxny centra XCoord, centru. Yong E 


- Mutáln(nxny) - 
“End; ( Roteşte E 


function Punct. Caracteristici: Sting S 


Sia conrea 3M); 
S:="'X => 
ie Codd NDS Quee oe 
S:=S +”, Y= Z+M; 
Câracteristici : SEE 

"End; { Caracteristici ) ` 

procedure Punct. Listeaza; 


-Be egin GE 
Guinea a(Caretersis) x 
"End; 1 Listeaza E 


3 SE procedure Cerc. Init(aX,aY, LE nos ue z 


Begin. 

` Punct EH SC 

Ro aRaza 5 9 55 
End; { Init} | pei iR 
procedure Gere Deseneară SURE MU 
Begin ` XM js 

Punct.Dese neazá; Ei E 

Graph. Cc Cord YCoonRa) 
End; { Deseneaza y IDE. 


cs SS 4. 2. 3. Implementarea metodelor desi Cere 


(unit-ul UGraph) 


a S À ; E UGraph) 
: ie 


EN (unit-ul Graph) 


Exemplul 42.3. Implementarea metodelor clasei Cere (continuare) 


procedure Cerc. Ascunde; 
var 
c: Word; 
Begin 
c:= Graph.GetColor; 
Graph SetColor(Graph.GetBkColor);: 
Punct.Ascunde; 
Graph. Circle Coord YCoord Raza); 
Graph.SetColor(c) "` 
End; ( Ascunde ) 
procedure Cerc.Mutiln(nouX,nouY:lnteger); 
begin 
Ascunde; 
Locate Jit(nouX nou); 


EU: Ar Mutin ) ; 
; "procedure Cerc. Translatează(pasntegen) ` 
a DES 


DX,DY : Shortlnt; GE E 
- CrtX,CrtY : Integer; UICE E 


- Desenează; 
CrtX : — XCoord; : SE 
CrtY := YCoord; - Sed Es 
While CeDirectie(DX,DY) Dk 
CHX := CrtX + DX * pas; SE 
CrtY := CrtY + DY "pas, SE 
MutăÎn(CrtX,CrtY) 
En 


d; 
End; ( Translatează ) . 
procedure Cerc. Rose ceru Loca unghi Integer; 


el Integer; 


nx:— XCoord; - x e icr ix 
ny:= YCoord; 


< 


otet Pune (ne ay;centru XCoord cet YCoordunghi; S 


 Moäfotom-ni SE EE 
End; { Roteste ) S A 
: procedure Cerc. Maárcste(CuCit: Integer); 


Ascunde, > o n ES X 


| CO End[MBege] | 0 0. 
Mo Annon Cere paza: Integer; 2. 


iu Graph 
unit-ul Graph 


oer Graph 
unit-ul Graph 


(Ceré.Ascunde] 
ÍCerc.Deseneazá) 


(Cerc.MutăÎn) 


(Cerc.Mutăln) 


à (Cerc.Ascunde] 


(Cerc.Desenează) 


IRA 


Raza :=R 
- End; ( Raza ) 
function Cerc. Caracteristici : String; 
var 


SM : string; 
b 


gn 
Ra 3 SMS, ; 
='+M; 
CARTER tus. Punct. Caracteristici + S . 
end; ( Caracteristici ) - 


În implementarea E claselor mai sus is definite s-au folosit proceduri si funcţii din 
două unit-uri: Graph (unit sistem, ce conţine extensia grafică a limbajului Turbo Pascal) şi 
UGraph (unit utilizator). Unit-ul UGraph este listat în 2.4.6.2. Pentru o mai uşoară accesare a 
claselor enumerate, s-au conceput trei unit-uri Turbo Pascal: ULoc pentru clasa Locaţie, UPctS 
pentru clasa Punct şi UCercS pentru clasa Cerc. Fiecare unit conţine în partea de interfaţă, 

„definiţia clasei, i iar în partea de unpiementare textele sursă ale metodelor. 


Utilizarea instanțelor cláselór Cerc $i Punct este prezentată în EE 424 $1422. 
Programul 4.2. 1 lucrează cu obiecte statice, iar programul 422 cu obiecte dinamice. 


Program ÎN ora 4.2. 1 SES = RU cu obiecte grafice statice) 
Uses Graph, EE genannt Dos; 2 Se SE 


C: Crea d. E E 
Be Prog am 421 zi RU ae DU e 
GE a z E a [trecerea im modul em 
P-Init(100, 200) - UE E > finifializarea obiectelor 
 CIni(15023030);- AU ET c e MR D QE s 
P.Deseneazá; — = EE {desenarea obiectelor) 
C.Desenează, - z : SE m 


` (listarea obiectelor) - 


P. Murau (200.300 300), (mutarea obiectelor) 

C Minte Coana + ES [c Coen -30); Se 

- P.Listeazá; 
C.Listează; `` 
SE ` 


: - (listarea obiectelor) 


Repeat 

: ; EE o 
E . Delay(100) E 
cro Until KeyPressed; ec E : =: ZE ee 
Read >>, > “(rotația cercului în jurul punctului) .- 
Re epeat ` d zs zt CS Ax SE Sa E E 4; S 
I AR PIRA Um EE ES AS 
Delay(100 i cae E 
4 ; Ee EE 

ST EE 
- P'Translatează(10 ^ 


{rotația punctului în jurul cercului) - 


(translatarea obiectelor) 


CloseGraph 
End. ( Program 4.2.1 ) 


(revenirea în modul te: 


Program Program 4.2.2; (lucru cu obiecte grafice dinamic | 


Us Graph, UGraph,ULoc, UPctS,UCercS,Crt,Dos; 
x d 


PointerLaPunct = ^ Punct; 
PointerLaCere = ^Cerc; . 
Var 
. PP:PointerLaPunct; 
|. PC: PointerLaCerc; 
Begin ( Program 422 ) 
InitGr; : 


P) 
PP ^ Init(100,200); 
New(PC); 
PC Init(150,230,50); 


PP ^.Deseneazi; = E 
PC^deseneah EE 


2 sabe in modul graf 
(alocarea obiectului dinamic referit dc F 


e Xe Se (alocarea obiectului dinamic referit de P- 


(desenarea obiectel 


PP listează e - (listarea obiectel. 


ReadLn; ` ` EE : 
; EE Mua aG: EE ~ mutarea obiectel. 
PC^.Mutidn(PC^.XCoord-50,PPC^.YCoord-30; ^ .— e 
PP ^ .Listeazá; c e Eo Mud Med UL UE 
PC ^ Listeazá; - SE - S 
Reader 
Repeat ` EE 
PP Roteetet Et 
- Delay(100) = - uude o cR 
Until KeyPressed —— —  —— 
ReadLn; | E UE 
Repeat ocupa E e a E rc 
JPC^;Roteste(PP ^51); -— —— — — 
Delay(100) ——— a S 
- Until KeyPressed; - Z 
ReadLn; ` UE 
PC” Tianslatează(10); — = — === 
PP ^ .Translatează(10); T CH EE 


„(listarea obiectel. 


e : TEN punctului în jurul cercul 


{rotația cercului în jurul punctu: 


E 4 


y S = 3 (translatarea obiectel: 
„A dealocarea obiectelor dinami 


DEPO REA S SE 

Diese BCEE ios : 
vL A en e M C T CUT => revenirea în modul te : 
s End {Program 422] — 9 098 e A, s AEN 


: Obiectele din clasele Punct şi Cerc reacționează diferit la mesajele Deseneazd, Ascu 
MutăÎn, Roteşte, Translatează, Listează. Numele metodelor apelate este acelaşi pentru o act 
dată, indiferent de obiect (punct sau cerc), sugerând acţiunea ce trebuie efectuată. Evid 
- metodele vor avea implementări diferite pentru cele două clase Punct şi Cere. Ar B interesan! 

"văzut dacă se poate lucra cu colecţii de astfel de obiecte polimorfe, colecții care conţin poin . 
` la obiectele respective. Un exemplu simplu este programul 4.2.3, ce reprezintă transpun: 


: programului 4.2.2, colecția considerată aici fiind un tablou A de două elemente, cu elementu 
tablou de tip PointerLaPunct. ` SL GEN 


E 
d 


Genre 
Ce ipo E 


be Det ZPO, 


Program Program 42.3; 


A SC SE 
Es Graph,UGraph,ULoc,UPetS,UCercS (încercare de polimorfism fără metode virtuale) 


„Crt,Dos; 
Type : 
PointerLaPunct = ^ Punct; 
PointerLaCerc = Gere. 
Var 
PP : PointerLaPunct; M 


PC: PointerLaCerc; 
A : Array[1..2] of PointerLaPunct; 
Begin ( Program 4.23 ) 


RCS -Init(150, 230 am: EE 
A[2]:= PC 

A[1] ^ Desenează; 
A[2] ^ .Deseneazà; MAII E Ie e z i ` 
A[1]” .Listează, - - m Zs ; SE (listarea obiectelor) 
A[2]^ .Listeazi; FS ee SE e 


InitGr; e x (trecerea î în modul grafic 
New(PP); s S (al geared obiectului dinamic referit de PP 
pP Init (100,200); > 

: = PP; (primul element din A este un pointer la Punct 
New(PC); - (alocarea obiectului dinamic referit de PC 


(A[2] este un pointer la Cerc 


(desenarea obiectelor) 


ReadLn; T CC COE d = 3 : > i SE 
- A[1] ^ MutăÎn(200, 300); S -- — — (mutarea obiectelor) 
A[2] ^ Mutäăîn(A[2] ^ X Coord sA] 2Y YCoord- a» E e E E 
A[1] ^.Listeazá; o. = — listarea obiectelor) - 
A[2] ^ „Listează;, A CS fr ase mE a 
‘Readln; - < E ples ten. a 
Repeat ` — a ~ {rotația punctului în jurul cercului} 
- A[1]^ Roste(AD]^, D; zx d E m : 

- Delay(100) = Za EE SS E: 
Until E : : m = ; 
Readln e on Eel eun Ur e ee : 
“Repeat E a rotația cercului în jurul punctului} 
A[2]^ RoeseAt]^ D SES EE 

Delay(100) Eee ca 
Until KeyPressed <e a PESE. 
: ES EE EE SS SE e: ue E (translatarea obiectelor) 

A | THE 
E ); c IM e E  {dealocarca obiectelor dinamice) 


— Dispose(A[2]); EE 


CloseGraph ` ` EE EE „(revenirea în modul text) 
„End. { Program 423) - SE EE 


la prima 
"Din păcate, deşi pro amele 4. 225 şi CR 23 sunt cclivalente semantic (cel puţin 
vedere), Gs dime diferit, în sensul că al doilea obiect (referit de A[2]), chiar 
- dacă este, instanţă a clasei Cerc, se comportă cao. E a clasei Punct. "Necazul" este Coni 
de instrucţiunea de atribuire; ER E A : Se 


Es 


şi nu poate fi evitat nici printr-un subterfugiu de forma: 


New(A[2]); ' {alocarea obiectului dinamic referi 

A[2] ^ „Init(150,230,50); ici tell 
deoarece protestează compilatorul (A[2] este PointerLaPunct, iar metoda Init din următoarea 
instrucţiune aparţine clasei Cerc). Acest program este o primă tentativă de lucru cu obiecte 
polimorfice. Reamintim Cá aceste obiecte sunt instanfe ale unor clase diferite, între care există 
relaţia de moştenire și care pot să răspundă la aceleaşi mesaje. Se-pune întrebarea: 


Cum se rezolvă lucrul cu obiecte polimorfice în Turbo Pascal? 


Analizând textele sursă ale metodelor clasei Cerc ce sunt redefiniri ale metodelor clasei 


Punct, constatăm că Mutáfn, Translatează, Roteşte şi Listează sunt identice sintactic (este clar că, 
semantic, acţiunile sunt diferite). Se pune întrebarea: ` S 


Nu s-ar putea ca metodele amintite să fie moştenite de la-clasa Punct? 


." Ráspunsulla aceste două întrebări este afirmativ. În Turbo Pascal, ca în toate limbajele 
orientate pe obiecte, acest lucru se realizează prin acţiunea conjugată a celor trei mecanisme 
discutate în secţiunea 4.1.5: constructorii şi destructorii, metodele virtuale şi legarea dinamică. Pe 
lângă acestea şi în strânsă legătură. cu folosirea constructorilor, s-a - prevăzut și ô extensie a 
„procedurilor standard New şi Dispose. Să le discutăm pe rând. xs 

n ; = : 
4.2.3. Constructori si destructori. Metode statice şi virtuale. Legare statică şi 

"dinamică. Implementarea obiectelor 


În exemplele discutate până acum, moştenirea a fost folosită pentru câmpuri (clasele 
Punct şi Cerc moştenesc de la Locaţie câmpurile X şi Y) şi pentru metode (ale superclasei, care 
nu sunt redefinite în subclase: XCoord, YCoord). Metode omonime (Desenează, Ascunde, Mută În, 
Translatează, Roteşte) au fost definite în clasa Punct şi au fost redefinite (toate) în clasa derivată, 
Cerc. ET $ 
; Mai mult, fiecare apel de metodă este rezolvat la compilare, în sensul că se deduce, din 
tipul receptorului, clasa a cărei metodă este apelatá. Din acest motiv, în programul 4.2.3 nu 
funcționează polimorfisinul dinamic: deşi PC este pointer la cerc și obiectul referit de PC este 
iniţializat ca atare, prin atribuirea A[2] : = PC are loco constrângere (elementele tabloului A sunt 
pointeri la punct) şi în continuare compilatorul va considera că A[2] referă un punct, selectând 
- în consecință metodele clasei Punct la întâlnirea receptorului A[2]. Această manieră de /egare a 
metodei la tipul clasei instanței a fost numită în 4.1.5.2 legare statică. 


Toate metodele prevăzute în exemplele discutate până acum sunt metode statice (implicit, 
orice metodă este statică în Turbo Pascal). Când un mesaj conţine apelul unei metode statice cu 
selectorul nume metodă, apelul se poate rezolva la compilare prin parcurgerea arborelui de 

“moştenire de la clasa obiectului receptor (cunoscută la compilare) spre rădăcina arborelui. Prima 

- metodă găsită ce are ca selector nume_melodă va fi metoda apelată Şi acest apelse rezolvă în mod 
obişnuit (ca apelul unei proceduri în Pascal Standard). Algoritmic, legarea statică pentru mesaje 
de forma. d 


obl.nume_melodă statica(listà de _parametri_actuali); 


sau ` ANT e 
.pob1 ^ nume _metodă_statică(listă_de_parametri_actuali);. 


135 


- respectiv 7 octeți pentru o instanţă a clasei Cerc: 


nseamnă: 


1. Se determină clasa receptorului (obl sau pob1^ 
tál 
sil pobi amar declarate ca variabile); ET ees 26 EE Sue 
€ selectează din dicționarul de metode al clasei 
D pasat pri i respective adresa punctului de intrare 


3. Se pune în cod apelul metodei respective (salt la puncta de intrare aferent procedurii . 
în cauză). 


Din punctul de vedere al implementării, pentru o instanță a unei clase se alocă un număr | 
le octeți, egal cu suma lungimilor, de reprezentare ale câmpurilor instanţei (la fel ca la TD 
cecord). 1 n cazul exemplelor de mai sus, se vor aloca 5 octeți pentru o instanţă a clasei Punct: , 


SizeOf(Punct) = SizeOf(X) + SizeOf(Y) + SizeOf(Vizibil), 


. SizeOf(Cerc) := SizeOf(Punet) + SizcOf(R). l 


Prin urmare, în timpul execuției, o instanță nu-şi "cunoaşte" clasa'sa. Acest lucru este valabil în 
situația în care clasele nu posedă metode constructor, toate exemplele anterioare fiind din această 
categorie: Rolul unui constructor este în primul rând acela de a ataşa fiecărei instanțe "semnătura" 
clasei la care aceasta aparţine. În Turbo Pascal acest lucru se realizează ataşând încă doi octeți 
reprezentării fiecărei instanţe. În spaţiul: astfel obţinut, constructorul va pune un pointer la tabela 


- de metode virtuale (VMT) a clasei la care apartirte. instanţa. Informaţia de instan[iere este 


accesibilă numai în citire, ea putând | fi modificată doar printr-un alt constructor. Reamintim că, 
pe lângă această funcţie (principală în POO), un constructor are de obicei sarcina de a inifializa 
câmpurile instanţei (rolul metodelor Init din exemplele discutate) sau. de a aloca memorie 
dinamică pentru instanţă sau pentru: acele. câmpuri ale acesteia ce referă variabile dinamice. 

: Distrugerea informaţiei de instanţiere se face printr-o- altă metodă specială, numită 


destructor în Turbo Pascal. În plus, un destructor poate realiza dealocarca memoriei dinamice 
alocatá de constructor. à Ss - 


[i 


: o clasă poate . avea mai i mulți construciori si destructori. Specificarea lor se face in 
definiţia clasei, în forma: a poe e ra 


7 


constructor 7 nume i constructori (parameti formali); : 


des = = 
destructor nume. destructor (parametri formal); [virtual]. 


iar implementarea | lors se face î în aceeași manieră ca i ENEE celorlalte metode, antetele 
ind: v C 52 danse => cs N geo 


' constructor. nume dean  conamucto(parameti Tora]: 


p. espe xc ah 


destructor. nume lasă nume. desrictor (parametri formali); 


eclararea metodelor virtuale. se face o ataşând' cuvântul c cheie virtual la ven 
SE în maniera: e : SS : 


procedure nume / metodi ramen. Jornál y virtual; 


» 


sau 


function nume_metodă| (parametri formali)] : tip; virtual; 


Înainte de a discuta rolul metodelor virtuale, să precizăm restricțiilė de proiectare și 
utilizare a lor, date sub pons următoarelor reguli- (deduse din regie R1-R6 prezentate în 
secțiunea 4.1): 


VI. Orice clasă ce posedă metode virtuale trebuie să aibă cel puţin un constructor. 

V2. În programul utilizator, o instanţă îşi va apela constructorul înaintea oricărui apel de 
metodă virtuală. 

V3. Orice specializare (rescriere )aunei metode vinuale à în descendenţii clasei trebuie să fie 
tot virtuală; 

` V4. Orice specializare (rescriere) a unei metode virtuale în descendenţii clasei trebuie si 

aibă exact acelaşi antet (acelaşi nume şi aceeaşi listă de ch i). 

V5. Constructorii nu pot fi fi virtuali. 


Pentru fiecare clasă ce posedă metode xut, compilatorul Turbo Pascal creează c 
tabelă de metode virtuale VMT, ce conține: 
- dimensiunea unei instanţe a clasei, 
5 2 numărul de metode virtuale; 
- pointeri la codul fiecărei metode (adrese de puncte de intrare). 
Aşadar, VMT este proprie clasei. Am văzut mai înainte că fiecare instanță creată cu un 
constructor poartă în ea "semnătura" clasei prototip, care nu este altceva decât adresa VMT. 
Apartenența unei MERE ob la o clasá datá nume clasá se poate testa in : Turbo. E astfel: 


EK. JypeOKob) = TypcOf(nume _elasă); 


iar faptul că două obiccte obl şi ob2 sunt instante ale aceleiași Clase prin: 

TypcOf(obl) = TypeOf(ob2); Bum ; 

Am văzut în 4.1.5 cámetodele virtuale Reb modelarea; comportamentului polimorfic 

al obiectelor. Dacá apelul : metodelor statice se rezolvá la compilare, apelul de metode virtuale sc 

rezolvă numai la execuţie. Astfel, concretizând consideramie: prezentate i în 4.1.5, un mesaj d 
forma: : 


. obl. o. metodă virtuala stă de „parametri. actuali; 


sau 
pob1 nume metodă „virtuala (st. de -parametr actuali; 


^ EI 
se rezolvă la execuţie în următoarele étape: iem BOE e 


SE “Se determină clas receptorului (obl sau pobl^), de cies adresa vM 
' corespunzătoare clasei sale, din informaţia existentă în instanţă respectivă; `. 
2 Se selectează din VMT adresa codului metodei specificate (adresa punctului d: 


intrare); 
73. Se lansează în execuţie” respectiva metodă. G face sålt la punctul de intrari 


corespunzător acesteia). -~ 


l 
Spre SE de legarea statică, unde contează e tipul clasei instanței (cunoscut 
M pile) SE manieră de legare a selectorului de receptor în timpul execuţiei a fost numit 


D 
CH d | : 
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a E See CEO faptul că se apelează metoda adecvată instanței, în 
e cu atributele ei din timpul execuţiei, şi nu metoda adecvată clasei statice a instanţei, 


X prin var. Un obiect 0, instanţă a unei clase 
, t c, poate fi consider at in douá 


a) la compilare, cándi se cunoaste clasa prototip (declaratá cu var o:c; ín Turbo Pascal); 
in NS moment se pot rezolva toate apelurile de metode statice ms prin: 
o.ms(...); 

b) la execuţie, când i se cunoaşte clasa efectivă s c (ca urmare a apelului unui 
constructor, de exemplu Init al clasei s_c, care va trebui să fie în arborele de 
moştenire al clasei prototip c): o.Inir(...); după acest moment (al apelului de 
constructor), orice apel de metodă virtuală mv cu receptorul o: o77v(...) va ţine 
cont de clasa efectivă s c şi nu de clasa prototip c. 


Ipostaza a) corespunde legării statice, pe cândb) corespunde legării dinamice. Cunoscând aceste 


lucruri, se poate explica necesitatea regulilor V1-V5 enunțate anterior: 


V1. Prezenţa imperativă a constructorului pentru clasele ce posedă metode virtuale: dacă 
. nu existá constructor, instanța nu va conţine spaţiu pentru adresa VMT, deci nu 
se va putea cunoaşte clasa efectivă a instanţei; 

V2. Apelul constructorului unei instanţe o trebuie să preceadă apelul oricărei metode 
virtuale de către o: numai după apelul constructorului se cunoaşte clasa efectivă 

a instanţei; S 

V3. Orice rescriere a unei metode virtuale trebuie să fie la rândul ei metodă virtuală: 
absenţa acestei reguli ar provoca combinarea celor două modalităţi de legare a 

metodelor, complicând implementarea legárii statice şi dinamice; 

V4. O metodă virtuală cu numele mv trebuie să aibă aceeaşi listă de parametri în toate 
clasele din arborele de moştenire în care ea este redefinită: acest lucru este impus 
de caracterul puternic tipizat al Pascal-ului (antetul metodei din clasa prototip, 
asupra căreia se face verificarea la compilare, trebuie să fie identic cu antetul 
metodei din clasa efectivă, care se va apela la execuţie). 

5. Constructorii sunt proprii fiecărei clase, deci nu pot fi virtuali; două clase diferite au 
tabele de metode virtuale diferite. 


4.2.4. Proiectarea şi implementarea metodelor virtuale 


. Vom relua specificaţiile claselor Punct şi Cerc în care vom folosi metode. virtuale. 
^ Conform precizărilor V1-V5, aceasta înseamnă că în fiecare clasă vor fi prevăzute: 
- un constructor; > à SES IET 
- un destructor (necesar pentru dealocarea obiectelor dinamice); 


- metode virtuale. : : E : IIS 
Ínainte de a discuta noile specificaţii, ne vom referi la lucrul cu obiecte dinamice in Turbo Pascal. 


~ Unobiect dinamic este alocat in memoria dinamicá (heap), find referit deun pointer ce 
conține adresa lui. Programele 4.2.2 şi 4.2.3 conțin exemple de obiecte dinamice din clasele Punct 


şi Cerc. Uzual, în situaţia: ; 3 


type pointer nume clasá = ^nume clasá; 
var pob : pointer nume clasá; 


Ly 


crearea unui obiect dinamic; se face cu ajutorul unei proceduri de iniţializare (numită Init in 


exemplul nosttu), în maniera: 


New(pob); (se alocă memorie dinamică pentru obiectul 


Să i dinamic referit de pob) 
pob ^ Jnit(...); (se apelează metoda Init) 


În versiunea 6.0, Turbo Pascal introduce extensii ale procedurilor standard New si Dispose, care 
se pot apelain cazul existenţei constructorilor, respectiv destructorilor. Astfel, extensiilé au sintaxa 
(nit este constructorul clasei nume_clasă, iar Done este destructorul acesteia): 


New(pob,Init(..)); - a 3» R 


respectiv 
Dispose(pob,Done(...)); 


„Acţiunile efectuate de procedura standard New în exemplul de mai sus sunt: 
1. Se alocă în memoria dinamică spaţiu pentru obiectul dinamic referit de pob, în 
: conformitate cu specificaţiile clasei nume clasá; Tec. 
` 2.Se apelează cu pob ^ ca receptor constructorul nit, care: 
2.1. pune în instanța pob ^ adresa VMT a clasei nume clasá; | | 
22. iniţializează (si eventual alocă dinamic unele dintre) câmpurile obiectului 
2 pob 2 SS Se 
Reciproc, procedura standárd Dispose (versiunea extinsă) realizează: 
1. Apelarea destructorului Done (cu pob ^ ca receptor), care: 
ga -1.1. resetează pe valorile implicite (si eventual dealocă unele dintre) câmpurile 
POS SE SE SE 
1.2. distruge în instanţa pob ^ adresa VMT a clasei nume clasá; 
2. Dealocarea din memoria dinamică a spaţiului pentru obiectul pob ^. ` 


7 


^ D e D : X 
Procedura standard New mai are o extensie, cu sintaxa: 


e pob :— New(pointer_nume_clasă,/nir(...); Er Ad EL 


caz in care New va intoarce un pointer de tip pointer nume clasá, efectuând acţiunile precizate 
anterior. Bineînţeles, Init trebuie să fie constructorul clasei nume_clasă. Se observă că în această 
situaţie apelul lui New are sintaxa apelului de funcţie şi nu de procedură. - SE 


Revenind la specificațiile claselor Punct şi Cere şi tinând cont de observaţiile făcute, 
acestea se vor scrie astfel: mE : a RUE T 


PointerLaPunct = ^Punc. | . . - : Qi 

„Punct = Object(Locaţie) Was cio DP CH SS 
constructorInit(aX,aY:Integer) |. ^. - SESS 
destructor Done; virtual; , — ^ —— ; 
procedure Desenează, virtual; «00 Ana 

- procedure Ascunde, virtual; DuC uires : 
function EVizibil : Boolean; ` dev un 
procedure Mutáin(nouX,nouY:Integer); i 
procedure Translateazá(pas:Integer); `" 
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procedure Roteste(centru:Locafie; unghi “Int 
function Caracteristici: S eger); 


procedure Listeazá(c.l: Integer); - 


private ` 
Vizibil : Boolean; 
End; 
, PointerLaCerc = ^ Cerc; 
Cerc = Object(Punct) 
constructor Init(aX,aY,aRaza: Integer); 
procedure Deseneazi; virtual; 
procedure Ascunde; virtual; 
procedure Măreşte(CuCit:Integer); 
function Raza : Integer; 
function Caracteristici : pem virtual; - 
private 
R : Integer; 


` Specificarea 4.2.4. Metode virtuale, ;Coustructori şi destructori 


Implementarea metodelor « este dată în exemplele 4223, iar peu constructori is i destructori in 
exemplul 424. E 


Peng 42. 4. Implementarea constructorilor si —— 


{ Punct tF 1 d 
. "constructor Puncte aeger). : 
Begin SS PE a a ; = 
ioc uim aie SOAM ER 
Vizibil :: = False ` ur E NE ES 
destructor Punct. Dones ; ee Ah Se 
Begin - & e SE ; A S -. 
Ascunde - Y MURCIA SE 
End; A Done } ` e e ae * 


3 | Ead mE E 


m Cerinte nainte) 
SS Ini(aXaY) 
R:- aRaza 

End; 1 Init] : 


Conparind adir 424 cu git 423( a clasă T se constată we 


; dinamic. De comp. în po 


— varP: Punct; / Cup ou os mc Ki 
C: Cerc; | i "x 


340 ` jm SRI AN OPE i SPI MUN. 


Die 2 A . 2 | 


mesejute Mutiin(100:200) va avea ca efect (cf. exemplului 4.2.2): 


P Ascunde; 
N „Locaţie. Init(100,200); E 
NP-Deseneazi (Punct.Desenează) 
pe când mesajul C. Mutin (100,200) se va traduce astfel: 
N 
C.Ascunde; X Cerc.Ascun 
Lócatie.Init( 100,200) (Cere duce) 
C.Desenează ; (Cerc.Deseneazá] 
Mai mult, când se lucrează cu obiecte polimorfice, ca in situația: 
var A:Array[1..2] of PointerLaPunct; 
` şi d Li s ; z 
AŢI] :=New@ointerLaPunct, Init (100,200)); 
A[2] = New(PointerLaCerc, Init(150,230,50)); 
mesajul A[1]^Mutäĵn(100,200) va avea ca'efect: — — ~ 
A Aande EE 
“Locaţie Init(100,200); —— = ~ SE EE S 
„ALI Desenează ` Vut suu e pe ea (Punct Desenează) 
“pe când mesajul AD^ Mutăîn(100,200) se va traduce astiel: - SE 
SC ATI Ascunde; SE Ss Ce zx Em = SE O AA cade 
. Locaţie.Init(100,200); — — . - — — DULCE E E D E c 


Se observă clar, în cazul obiectelor polimorfice, maniera în care se stabileşte la execuţie metoda 
virtuală adecvată instanței receptor. COLE e ARES ATE : 


= Programele 4.2.1-3 prezentate anterior vor. nctiona corect în prezenţa noilor specificaţii 
ale clasei-Cerc: În fond, nu este vorba de modificarea algoritmilor care implementează metode 


acestei clase, ci de o utilizare mai eficientă a moştenirii prin utilizarea metodelor virtuale. Deaceastă ` 
~ datási progrâmul 4.2.3 va funcționa corect. ` — D SUR geo OE : ; 


As 4.2.5 Clase abstracte 


În proiectarea ierarhiei claselor, există unele dintre ele care nu vor poseda instante. Rolul lor 
este o mai bună structurare a acestei ierarhi; ele colectánd caracteristicile comune (câmpuri şi metode) 
pentru mai multe clase descendente. Clasa Locaţie din specificarea 4.2.1 este un asemenea exemplu 
de clasă abstractă. Rolul ei este definirea caracteristicilor (coordonatele, metodele de initializare şi 


de accesare a acestora) comune pentru clasele,descendente. Toate aceste clase, având clasa Locaţie ` 


~ în arborele lor de moştenire vor poseda atributele respective. - - 


Pe de altă parte, Locaţie poafe fi considerată o clasă abstractă şi deoarece comportamentul. - 


"ei nu este suficient de bogat pentru a fi utilizat de instanțele sale. Astfel, Locaţie nu posedă metode 
de vizualizare sau manipulare, cum posedă descendentul său direct, clasa Punct: $ 


melt Mud 100,200) va avea on efbot of, exemplului 4.2.2): 
N 


a DAgoundo, unc 
\ Luene Init 100,200); Lunet Aud) 
NP Deseneazü (Punct, Deseneazá) 


pe când mesajul CMutălu (100,200) gp va traduce antfel: 


CG Aender ' Cero, Aur 
Locnpio.Ini(100,200) Accus 
C.Dosenoază | | (Cerc.Deseneazi) 


Mui mult, când se lueroază eu obieete polimorlioe, ca în situația: 
var AArtay| 1.2] ot PolnterLaPunet 
y Şi V À 


ALL] = New(PointerLaPunet,Init (100,200); 
AI = New ege CH NUM 


mesajul ALI] Mutin(100,200) va avea oa afoot: 


ALI Ascunde; “aula | .. (Punct.Ascunde) 
Locaţie. Init(100,200); ` pibe i ^" 
„ALI! Dosenează RN SEM ha ` ` (Punct.Deseneazá) 
re când mesajul A[2]^ Mutăta(100,200) se va traduce astfel: 
A[2]^ Ascunde; uM he En (Cerc. Ascunde) 
Lovație,Init(100,200); EN EE SE 
A[2]^Deseneaxd |, SENSN AU NETS : (Cerc.Desenează) 


Se observă clar, în cazul obiectelor polimorfice, maniera în care se stabileşte la execuţie metoda 
virtuală adecvată instanței receptor. MC 


` Programele 4.2,1-3 prezentàte anterior vor funcționa coreot în prezența noilor specificaţii 
ale clasei Cere: În fond, nu este vorba de modificarea algoritmilor care implementează metodele 


acestei clase, ci de o utilizare mai eficientă a moştenirii prin utilizarea metodelor virtuale. De această ` 


dată şi progrâmul 4.2.3 va funcționa corect, 
4.2.5. Clase abstracte 


În proiectarea ierarhiei claselor, există unele dintre ele care nu vor poseda instante. Rolul lor 
este o mai bună structurare a acestei ierarhi; ele colectând caracteristicile comune (câmpuri şi metode) 
pentru mai multe clase descendente, Clasa Locaţie din specificarea 4.2.1 este un asemenea exemplu 
de clasă abstractă, Rolul ei este definirea caracteristicilor (coordonatele, metodele de iniţializare si 

` de accesare a acestora) comune pentru clasele descendente, Toate aceste clase, având clasa Locaţie 


în arborele lor de moştenire vor poseda atributele respective, - 


Pe de altă parte, Locaţie poate fi considerată o clasă abstractă şi deoarece comportamentul ` 


ei nu este suficient de bogat pentru a fi utilizat Ae instanțele sale. Astfel, Locaţie nu posedă metode 
de Meeting sau Sag er ipia posedă descendentul său direct, clasa Punct, 1 
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4.2.6. Colecţii de obiecte polimorfice 


4.2.6.1. Liste 


În programul 4.2.3 este prezentat un exemplu simplu de colecţie de obiecte polimorfice, 


„depozitate în tabloul A cu două elemente de tip PointerLaPunct. O altă manieră de implementare 


a unei colecţii de obiecte va folosi o listă simplu înlănţuită. Întreaga colecţie poate fi considerată 
ca o nouă clasă, asupra căreia se prelungesc operațiile proprii obiectelor ei. În exemplul 4.2.5 este 
prezentată specilicarea si implementarea clasei Lista. 


» 


Exemplul 4.2.5. Specificarea si implementarea clasei Lista 


Unit UListF; n ( gestionarea unei liste simplu înlănțuite ) 
Interface ` 4 de obiecte grafice } 
Uses 
UPctD; 
` Type 
PointerLaNod = ^ Nod; M 
Nod = Record ` ; EE 
Element : PointerLaPunct; ` 
Precedentul : PointerLaNod 
End; : e 
“PointerLaLista = ^Lista; 
Lista = Object eN N 
'- Constructor Init; 
Destructor Done; virtual; — ^ == = X SUCI SE 
Procedure Adaugüá(Elem:PoinerLaPunc); — 077 7 
Procedure Listează; Susp e e e ce 
Procedure Desenează; Eccc I E 
Procedure Ascunde; EE 
Procedure Roteste(unghiInteger); ee 
Procedure Translateaza(CuCitInteger); ———— 
Procedure Măreşte(CuCitiInteger); —. —— 


Private EE 
Ultimul : PointerLaNod; ` 
“End; { Lista object ) E ae 


Implementation : 
Uses UCET PSU 
UCercD;UArc,USeg; =. ~ 

-.—. Constructor Lista.Init; 

: Begin IEEE ROSE 

parl "epe o E 
-* Destructor Lista.Done; ` ACRES dao 

Var fp í 

.N:PointerLaNod; . 

Begin . V 


XL x 


EE E EC ——X 


C. 


MERE A au 


While Ser < > Nil do 


Begin 
N: = Ultimul; 


- 


Ultimul AN „Precedentul; 
Dispose(N ^, Element „Done); 


Dispose(N) | 
End; 


End; ( Done ) t 
Procedure Lista. POM KE: PointerLaPunct); 
Var 


N 


N : PointerLaNod; 


Begin 


New(N); 


N ^ Element = Elem; 
N^ Precedentul = Ultimul; 


Ultimul : - N 


End; ( Adauga ) 


Var 


Procedure Lista. Eun 


N: PointerLaNod; 


Begin 
N: = Ultimul; 


While N < > Nil do. 


Begin 


N^ Element? 


.Listeazá; 


N := N Precedentul 


End; 


End; ( Listează ) 


Procedure Lista.Desenează; 


Var 


N : PointerLaNod; `` 


Begin 
N := Ultimul; 


While N < > Nil do 


Begin 


N^.Element ^ 


N:-N^ museum 


End; 


End; ( Desencazá ) 2 


. Var 


Procedure Lista.Ascunde; 


N: PointerLaN od; 


Begin 
N:= = Ultimul; 


While N < > Nil do S 


Be 


pin 
NC Element ^ 


Ascunde; 


N := N^ .Precedentul 


.Deseneazá; . `- 


End; 
End; ( “Ascunde ) 
Procedure Lista. Roteste(unghi: Integer); 
ar 
N,U : PointerLaNod; 
Begin 
N := Ultimul; 
While N < > Nil do 
Begin 
IN” ee Nu 
then U : = Ultimul 
else U := N^ Precedentul; 
N ^ Element ^ .Roteste(U ^ -Element ^ ,unghi); 
N:i-N^ .Precedentul 
End; 
End; ( 'Roteste ) 


SE Lista. Translatează(CuCit: Big 
ar 


N: : PointerLaNod; 
B 


While N < > Nil do 
` Begin 
N^ Element ^ ranstează Cuci); 
N := N” Precedentul . NS ED 
End; ) Sese 
End; ( 'Translatează | SRR BY E ANA har tea e 


Procedure Lista. Maregte(CuCit: E à EN 
"Var | a an ese 
N : PointerLaNod; d E AE ZE 
PC: PointerLaCerc; 
` Begin i | 

N:= Ultimul; | 
E <> Nil do 


e E TypeOf(N ^ EE EE or 
E zi „Element N $ TypeOf(Arc)) 
ben | EE x : 
- Begin » 25 
PC:= : PointerLaCere(N ^ Element); 
POL Máreste(CuCit) = E 
End - SEE Af 
; „else N ^ Element ^ Darana S ` 
ON: = N^.Precedentul RU E AERE ces CMM er 
3: - End; z NC . 
“End; ( "Măreşte, E 
- End. FLOR SS 


a 


În afara claselor menționate mai înainte, în acest exemplu se folosesc încă două 


Arc - clasă d 1 ală a clasei Cerc, a cürei specificare pie 
V gi im | mentare e 
5 Ste prezentată î in exemplul 


Segment - : clas derivată a clasei Punct, prezentată în exemplul 4.2.7 (unitul USeg) 
N 


A Exemplul 4.2.6. Specificarea $i implementarea clasei Arc 


Unit UArc; 
( Obiecte polimorfe. si metode virtuale J. ] 
Interface > 
~ Uses ULoc,UPctD, UCercD; 
Type 
PointerLaArc = ^ Arc. 
Arc = Object(Cerc) 
"constructor Init(aX,aY „aRaza,aUngkil, Unghi: IST 
procedure Deséneazá; RU 
- procedure Ascunde; virtual; - 
Function Unghil : Integer; 


Function UnghiF : S 
function Caracteristici: String; virtual; 
private ` : 
ULUF: Integer; EE 


Implementation LP. ORE RR CR Eus UE LS 
Uses Graph,UGraph; EE GE SE SE 
{arc} ; : 

- — constructor Arc. Init(aX, aY, aa aUngil Ung besch 
Beem E E 

Cerciniu(aX a V ,aRaza); UU UL LUST ace is EE SC 
e - SC GE > Se 

= ur. 
pad d Init ] - 


Draco dune Arc. Deepen 

„Begin ` ` SE SE 

Punct. Dort : ; 
Graph. Arc(XCoord, YCoord, Ung Und Sch 

^ End; { Desenează } ` : 

- procedure Arc Ascunde: papat EI UE Qu D d 

e; Word; SE EE 
Begin JJ Ep) PS 
€i Graph. GetColor; ` JA E TIERE RD : 
Graph. SetColor(Graph. GetBkColor); be rel Ea aia 
Punct.Ascunde; — ` e e: 

(4. - Gra ph.Arc(XCoord, Y Coord, Unghi Ung, Raza): bus 
Graph; SHE piete, DEE 


< e D 


End; ( Ascunde ) 
function Arc.Unghil : Integer; 


Begin 
Unghil : = UI * 
End; ( Unghil ) 
function Arc.UnghiF : Integer; 
Begin 
UnghiF := UF 
End; { UnghiF } 


function Arc. Caracteristici: String; 
var 
SM: string; 
begin 


Str(Unghil 3 M); 


S:=",dela =°+M; 
Str(UnghiF: 3,M); 
S:=S +’, pinala = '+M; 
Caracteristici : = Cerc. Caracteristici + Sa 
- end; ( Caracteristici ) 
end: a Unit UArc} ; 


Unit USeg; E 
- 4 Obiecte polimorfe si i metode virtuale d : 
Interface 
SIE E 
ULoc,UPCD; . 
Type <- 
PointerLaSegment = o Segment; 

- Segment = Object(Punct) — TET 
constructor Init(aX,aY,aL, aP: duse ROAST 
procedure Desenează; virtual; 

- procedure Ascunde; virtual; . 
function Lungime : Integer; 
function Panta : Integer; — 
. function XOrigine:Integer; . 


function YOrigine : Integer; SE S 3 MM SE 


function XCapat:Integer; ^ 
function YCapat : Integer; `" — X 
function Caracteristici: String; abs X 


procedure Roteşte(centru: Locaţie; ue ëch EE 
private. S eM e UP 
SE, 5: 
Pp: Integer ; e: 
End; =s 


146, 


1 
y 


1 


XI: 3 2 
“Exemplul 4.2.7. pen ŞI implementarea EE A Segment 


{lungime } 


EE Ze GE BC unghiul cu directia pozitiva a a axei Ox} 


Implementation 
Uses Graph,UGraph; 
{ Segment ) 
Ge ess Segment. Init(aX aY, aL,aP:Integer); 
e 
Punct.Init(aX,aY); 
L:-'aL; 
P:—aP 
End; { Init } 


uneia Segment Lungime : Integer; 
Begin 
Lungime := L 
End; ( Lungime ) 


function mI Integer; , 
B 


Panta : = 
End; { Panta | 
function Segment.X Origine : Integer; 
Begin E 
 XOrigine : = XCoord . 
„End; ( XOrigine ) 
function Segment. YOrigine : Integer; 
Begin 


End; ( YOrigine ) 
function Segment.X Capat : Integer; 
Begin 
XCapat : = XCoord + trunc(L * cos(P*Pi/180)); 
End; { XCapat ] 
function Segment. YCapat : Integei; 
Begin 
YCapat : — YCoord + trunc(L * sin(P*Pi/180)); 
' End;{ YCapat ) : 
procedure Segment. Desenează; | 
„Begin 
MoveTo(XCoord, YCoord); ` 
Punct.Desenează; 
„LineTo(XCapat, Y Capat); 
End; (Desenează )  — 
:.. procedure Segment Ascunde; 
var 
c: Word; 
Be 
= : ces Graph GetColor; * 
. . -  Graph.SetColor(Graph. a 
` MoveTo(XCoord, Y Coord); 
Punct.Ascunde; - 
LineTo(XCapat,Y Capat); 


Graph.SetColor c 
End; { Ascunde N 


function Segment. Caracteristici : String; 
var 


S,M : string; 
bed 


gin 
Str(Lungime:3,M); 
S:=) Lungime ="+M; 
Str(Panta: 3,M); 
S:-S + Panta =°+M; 
Caracteristici : = Punct, Caracteristici SS 
end; { Caracteristici ) 
procedure Segment. Roteste(centru;Loca[ie; unghi: Integer); 
ar 
nx,ny: Integer; ` 
Begin 
nx := XCoord; SERE 
ny:=.YCâord; se 
RotetePunei (any entra KC XCoord centru. v YCoord sgh) 
e ; 
P:=P + unghi = ze oe 
crabe dutem m em 
" Desenează ` SE 
~ End; ( Roteşte) - SE 
Se ES 2o -o x e ee EM 


RS uM 


fos 


Metodele clasei Lista s se împart în două categorii 


- metode proprii listelor: zm 
Init - constructor, creeazá o listă vidi 0e 
- Done - destructor, dealocă elementele listei; .. 
Adug- adaugă | un nou element la coada mus 


- metode ce vor reflecta comportemcatul obiectelor memorate- în elementele listei: 
— Listează - listează caracteristicile fiecărui element din listă; 
. Desenează - desenează fiecare obiect din listă; 
Ascunde = ascunde fiecare obiect din. lisi; - 
Roteyte - roteşte fiecare obiect din listă cu acelaşi unghi, în jurul precedentului obiect din 
listă (prin parcurgerea circulară a listei); 
- Translatează - translatează fiecare obiect din listă cu aceeaşi mărime; 
Măreşte - măreşte raza fiecărui obiect rotund din listă cu aceeaşi mărime. 


A doua categorie dé metode foloseste n plin apelul de metode virtuale, fie direct, fie 
indirect. O atenţie specială trebuie acordată metodei Măreşte, care nu este comună tuturor 
claselor menţionate, fiind proprie numai claselor Cere şi Are ( prototipuri de obiecte rotunde). În 
implementarea ei, se foloseşte funcţia TypeOf pentru TERNS clasei efective a obiectului. 
„O altă soluție de implementare ar fi adăugarea metodei virtuale Măreşte la clasa Punct (la care 
ca n-ar Des nimic sau Penta ar Bee obiectul), caz în care implementarea metodei Măreşte 


z 


doc 


Meo) pr tram 
romae. Lei Het 
Sr 
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a clasei s-ar face în acecagi manieră ca şi metodele anterioare, Aceasta se poate realiza astfel; 
- là clasa Punct se declară metoda virtuală Măreşte, care se implementează astfel: 


Procedure Punct.Müregte(CuCit;Integer); 
Begin 
Deseneazli 
End; ( Măreşte ) 


- la clasa Cere so declară Măreşte ca virtuali; 
- la clasa Lista se modifica implomentarea metodei Măreşte astfel: 


Meet Lista.Máregte(CuCit: Integer); 
ar 
N : PointerLaNod; ` 
PP : PointerLaPunct; 
Begin 
N:-Ulimu; ~ - 
- While N « » Nil do 
Begi * 


egn ; 

PC : = N^.Element; S 

mans Máreste(CuCit) LES 
= N? „Precedentul EX 


Rud; Sn SE 
End; ( Măreşte ) EE 
Lucrul cu obiecto polimorte este ilustrat în SE 4. 2 4, listat în continue, 


Program Program . 4.2.4; e Mu m Ape CNET 
( Obiecte polimorfce si oT 
Uses Graph UGraph,U UPctD, UCereD Jo USeg int Crt;Dos;  - 


So Lista; 

Begin { Program. 424) CD S 

InitGr; e 

L.Init; ; 

L Adauga(New(PointerLaCerc,Init(305, 136,5); S 
L.Adauga(New(PointerLaPunct,Init(300,150))); : N x 
L.Adauga(New(PointerLaSegment,Init(400, 100,40, s» tQ E EE S 
L.Adauga(New(PointerLaCerc,Init(400,100, 40); ceu EUM EISE 
d LESE ,100))); READ. AUS 
L.Adauga(New(PointerLaArc,Init(151,82,25,90 180); 


L EN 300); NONE AMET S S 
Liesch , S meet NS ^ S 


LTranslateazi(00; |... 00. (0 


Repeat NA 
- L.Rotegte(-1); , e s JUS S 
- Delay(100) Su E E Pus 


^d 


Until KeyPressed; 

ReadLn; 

Repeat 
L.Máreste(1); 
Delay(1000) 

Until KeyPressed; 

ReadLn; 

Repeat 
L.Mărește(-1); 
Delay(1000)  . 

Until KeyPressed; 

ReadLn; . 

L.Ascunde; 

L Done: 

CloseGraph 


End. 


- Unit UGraph; - : 
Interface. - 


{ Program 42.4 ) 


4.2.6.2. Unitul UGraph 


Pentru PEINE unor. funcţii grafice specifice exemplelor E anterior, s-a 


proiectat unit-ul UGraph, ce <xporlă e sen de astfel de operai: Ps sursă este prezentat în 
- continuare, în emu 42 A. : 


procedure I InitGr; 


function CeDirectie(var. Diră, DirY : Short) i Boolean; | 
.procedure OutTextLN(S:String); —— -- 2k 
procedure Roc xy: Inte : 


ee yore 


Uses: = 
Graph.Crt; - 
Const E 
"PathToBGI- cóc unser 


Mar 


function CeDiretie(var DirX, Do: GE Boolean; 


„150 


Cod ear: Byte; ) 
Gata; Boolean, 
egin 

DirX: = 0; DirY : = 0; 


 CeDirectie;— True; ~ 
Repeat . mu 


Gata; = True; 


Gamme? GrapiMode: Integer; 


^ 


CodCar := Ord(ReadKey); ! 


Sl exportă operaţii generale ) 
{ pentru interfaţa grafică | 


TN 


` { stabileşte direcţia de translatare H 
( stabilită prin tastele săgeți ) 
Si a taya se termină cu ENTER } - . 


- € citire tastă ) 


N 
Case CodCar of 
0 : Begin 
CodCar : = Ord(ReadKey); 
Case CodCar of 
JO PA Goa d 
80: DEN := 
75: DirX :— Er 
77: DuX:= 1; 
else Gata : = False; 
End; 
End; 


13 : CeDirectie := falsă — 
else Gata : = False 
End; 
Until Gata; 
End; ( CeDirectie ) 
Procedure InitGr; EA 
Begin < 
DeteciGraph(GraphDriver, np Mad ER 


InitGraph(GraphDriver,GraphMode, PathToBGI); - 


. If GraphResult < > BOE 
then: - 
Begi 


If GraphDriver = gFileNotFound 
^ then. 
WriteLn(i in > Path ToBGI, SA 
"Modificati "PathToBGI" in acest unit 22 


ReadLn; 


End; {nitar} SE = E: = 


procedure OutT exLNG: Siring); 


Ze ext(S); ` 
MoveTo(0,GetY + 12). 
-- End; { OutTextLn ) 


— precedure RotestePunct(var Xy: integer SEH Juge) 
| roteşte punct 


rd dy ambe sucus: ; Real; 
Begin 
dx: = X-CX; 


dy : = y-Cy; 
EAE sart(dx* de dy*dy); 
If r — 0.0 EA 
then Exit; TN s 
sf:=dy/ tr » € 


EE SE 


] WriteLa( Apasati ENTER .. A SE 


{ tastă funcţională ) 


{ săgeată sus } 

{ săgeată jos | 
{ săgeată stânga 
{ săgeată dreapta 


(ENTER) 


` Liniţializarea regimului grafic ) 


4 scriere text în mod grafic ) 


ul imi (excy) } 
a (e) anu ca SNRA, 


{ noile coordonate sunt tot (xy) } 


[st 


cx dx / T; 

uu : = unghi * pi / 180; 

su :— sin(uu); 

cu : = cos(uu); 

c:= cf * cu- sf * su; 

$:— sf * cu + cf rau: 

X:— CX + round(r * c); 

:= €y + roundir * s); 

End; ( RoteştePunci ) 


End. ( UGraph ) 


43. DEZVOLTAREA ORIENTATĂ PE OBIECTE A PRODUSELOR PROGRAM 


Programarea orientată pe obiecte, începută cu Simula 67 si Smálltalk, este astăzi tot aşa 
de consacrată cum era acum 10-15 ani programarea structurată. Se cunosc rezultate notabile ale 
aplicárii POO la realizarea de baze de date (Object-Oriented Data Base Management Systems . 
OODBMS), interfeţe utilizator interactive (Object-Oriented Graphical User Interface OOGUI) 
sisteme distribuite, sisteme de operare. : 


, Asacum programarea structurată (în sensul restrâns al termenului) a influențat metodele 
de analizà şi proiectare a produselor program (vorbindu-se de analiză şi proiectare structurată), 
programarea orientată pe obiecte a influenţat și continuă să producă mutații în metodologia de 
„realizare a aplicaţiilor soft. Concluzia este că ideile orientării pe obiecte pot fi folosite nu numai 
la implementare, ci şi la celelalte faze ale procesului de dezvoltare a programelor: analiză, 
specificare şi proiectare. e ie M TTE z 


EE 


Dezvoltatea orientată pe obiecte a produselor program (Object-Oriented Software 
Development, OOSD) cuprinde cele trei etape importante ale ciclului de viaţă: 


1. Analiza orientată pe obiecte (Object-Oriented Analysis, OOA); 
2. Proiectarea orientată pe obiecte (Object Oriented Design, OOD); 


3. Programarea orientată pe obiecte (POO). ` S 


Acestea sunt etapele generice a ceea ce numim modelarea orientată pe obiecte (Object 
- Oriented Modelling; OOM). Am inclus aici și programarea orientată pe obiecte deoarece, în 
- această viziune a orientării pe obiecte, programul este văzut ca un model, fiind format din obiecte 
care interacționează; acţiunile întreprinse în program se fac de către obiecte şi cu ajutorul lor. 


- — — * 4,32. Modelarea orientată pe obiecte 
f Regula de.bazá a modelárii orientate pe obiecte se poate enunja astfel: 


Ré 


E „Arhitectura aplicaţiei reflectă structura domeniului problemei. 


f "Considerăm o problemă P (din. lumea înconjurătoare). Pentru rezolvarea ei trebuie 
realizat un produs program PP. În lumea reală, universul (domeniul) problemei P este format din 
fiinţe și lucruri (subiecte, obiecte) şi acţiuni asupra lucrurilor. În produsul program datele vor 


p 


152- 


cuantilica fiinţele şi lucrurile, iar acţiunile se vor reali i ii : 
; m ; icy iza prin operaţii asupra datel i 
operaţiile vor forma domeniul soluției (PP). perap asupra datelor? Datele wi 


În cazul descompunerii funcţionale, modelarea parcurge două etape: 


1 Se începe cu ceea ce sistemul (problema) P face (trebuie să facă); 
2. Se determină funcțiunile necesare; care se consideră ca bază pentru structurarea 
programului PP în subprograme. PUE 


Am discutat in capitolul2 dezavantajele descompunerii funcţionale. Să vedem cum se face 
modelarea orientată pe obiecte: 3 


1, Se începe cu ceea ce face sistemul să funcţioneze: 


NU te întreba ce face sistemul! MU 
întreabă-te ce (cine) îl face sd se comporte ASA?; 


25Se examinează: domeniul problemei, pentru a găsi entităţi care au limite (frontiere) 
fizice sau conceptuale ce le separă de restul domeniului; 

3, Se utilizează entităţile şi relaţiile dintre entităţi pentru a concepearhitectura sistemului 
(aplicaţiei). EE E SS z > 


N X rm 


În această abordare, — 


funcţiile aplicaţiei Sunt acţiuni făcute de sau cu ajutorul entităţilor. 


Între avantajele abordării orientate pe obiecte regăsim o parte dintre cele menţionate la 
programarea dirijată de date (programarea - bazată pe obiecte, PBO): O altă definiţie a 


4 


programării orientate pe obiecte ar putea fi: - 
POO = PBO + moştenire + polimortism + legare dinamică 
Etapele de mai sus sc bazează pe următoarele constatări: KN : 


1. Entitátile sunt mai stabile decât funcţiile (nu sunt aşa de volatile); ` 


2. Întreţinerea aplicaţiei este mai uşoară dacă. complexitatea legăturilor dintre ` 
dx componentele ei este mai mică, ^... 0. 
` .. 3. Componentele soft obţinute sunt mai coerente şi deci mai uşor reutilizabile; `- 
4. Tranzi(ia de la analiză la proiectare si la implementare este naturală: modelul 
`; - conceptual nu se modifică. - . Ss CEU DE : 


; 4.3.3. Analiza şi proiectarea : Nus : 

În capitolul I am definit cele două etape importante ale procesului de realizare a 

produselor program. Vom încerca în cele ce urmează să le redefinim, în contextul orientării pe 
obiecte. - - SERO ES Sd EE Sre o 

i Analiza orientată pe obiecte este procesul de identificare şi definire a claselor (obiectelor) 

ce aparțin domeniului problemei. Aceste obiecte rezultă din enunţul problemei, din specificarea 

acesteia gi din cerinţele beneficiarului. Obiectele aparținând domeniului problemei pot fi: 


D 


evenimente, organizații, sisteme, procese, locaţii, proceduri/funcţii. 


Proiectarea orientată pe obiecte este identi; 1 j 

E 1 À pr ^ procesul de identificare şi definire a clasel 
Meses ce aparțin domeniului soluției. Proiectarea unui produs program trebuie să EERE 
ouă mari clase de probleme, prima proprie problemei de rezolvat, ce constă din gestionarea 


obiectelor din domeniul problemei şi a doua generală, valabilă T 
modelarea interfeţei utilizator. d SC See 


Obiectele ce aparţin domeniului soluției rezultă deci atât din specifi i câ 
e i l pecificarea problemei cât 
şi din soluțiile de rezolvare adoptate (maniera de realizare a interfeței utiliter. à intrárilor/ 
iesirilor, a gestiunii evenimentelor). 


Proiectarea orientată pe obiecte produce arhitecturi bazate pe obiectele pe care produsul 


program le manipulează şi nu pe funcţiile acestuia. Programele rezultate sunt considerate colecţii 
structurate de obiecte. i = S 


Analiza şi proiectarea nu sunt în întregime separate în procesul de dezvoltare orientată 
pe obiecte a produselor program. Analiza se referă la comportamentul dorit al sistemului şi este 
procesul de identificare şi modelare a claselor de obiecte din DOMENIUL PROBLEMEI care 
sunt ESENȚIALE, împreună cu stabilirea relațiilor şi interacțiunilor naturale dintre acestea. 
Proiectarea se referă la inventarea (conceperea) sau alegerea claselor de obiecte pentru 
DOMENIUL SOLUȚIILOR şi stabilirea relaţiilor logice şi interacțiunilor dintre ele. În plus, 


proiectarea trebuie să decidă STRUCTURA FIZICĂ a sistemului. 
„4.3.4. Metode de dezvoltare orientate pe Obiecte ` 
Aşa cum am arătat în preambulul acestei secţiuni, programarea orientată pe obiecte a 
influenţat şi metodele de dezvoltare a produselor program. Ca o dovadă în sprijinul acestei 
.. - afirmaţii, în ultimii ani au apărut o serie de metode de construire a progrâmelor, care exploatează 
facilităţile oferite de limbajele de programare orientate pe obiecte. Există în literatura de 
specialitate numeroase monografii şi studii dedicate acestor metode, între care menţionăm: 


- Cartea lui Meyer- [Mey88], bazată în special pe limbajul Eiffel, care propune o 
EECH DEET 
- - monografiile lui Coad şi Yourdon [Coa91a,b], dedicate analizei şi proiectării orientate 
pe obiecte; > SE SES 
- cartea lui Booch [Boo91]; ` SEE : 
- studiul [Arn91], dicar comparării a 5 astfel de metode de construire de programe: 
« 7 - - HOOD [HOO90]; S : 
- Buhr[Buh91] ` 
. - Booch [Boo91]; . : 
^ -Rumbaugh et E uer ; 
-- Wirfs şi Brook [Wir91], : GS 
. ,dintre care preis douá sunt orientate pe pachete (folosind Ada ca limbaj de 
^implementare), iar celelalte suportă integral (sau aproapeintegral) conceptele orientării 


~ 


obiecte; ` à EE 
Pronctoda propusă de Civello si Mitchell [Civ93], care và fi detaliată in cele ce urmează. 


S 43.5. Metoda propusă de Civello şi Mitchell. 
Vets acestei metode ([Civ93]), autorii s-au folosit de monografiile bi Coad şi 


+ D D 
Yourdon şi metodologia propusă de Booch, Metoda 
experienţei lor în acest domeniu. 


pe care o propun poartă, firesc, amprenta 


În metoda propusă de Civello si Mitchell (notată MCM în continuare), dezvoltarea de 
programe este incrementală si iterativă. Metoda este incrementală deoarece aspecte diferite ale 
proiectului sunt construite în paralel, în paşi mici, iar deciziile asupra unui aspect afectează 
deciziile asupra celorlalte laturi ale proiectului. Caracterul repetitiv, iterativ al metodei MCM 
(regăsit, de altfel şi la alte metode clasice de proiectare), constă în aceea că aceleaşi activităţi sunt 
efectuate (aplicate) la nivele diferite de abstractizare, iar deciziile luate la un nivel dat pot afecta 
deciziile luate la alte nivele. 


Etapele generice ale metodei MCM sunt: 


1. Identificarea obiectelor (claselor); 
2. Precizarea structurii statice - 
(definirea claselor şi a relaţiilor dintre ele); 
3. Precizarea comportamentului dinamic 
(definirea proceselor şi a operaţiilor); . 
4. Evaluarea modelului; sS SE 
3. Implementarea claselor. TRECE 


Etapele 2-4 pot face reveniri la etapele anterioare. 

AUN Fiecare etapă înseamnă efectuarea unui grup de activităţi, din care rezultă o serie de 
produse. În marea lor majoritate, produsele formează ceea ce numim dociimentaţia procesului ` 
de elaborare a produsului program. Descrierea documentaţiei este făcută în 4.3.5.7. 


43.5.1. Identificarea obiectelor CS GES 


^ 


' entităţilor care-le detectează şi a entităţilor care le gestionează. Pentru reducerea complexităţii 


„1, Diagrama de subiecte (subject diagram) RER 
3. Lista de evenimente T Ee = DE 
4. Diagramele proceselor SC pus 
Vom SE continuare două activităţi esenţiale ale acestei etape: identificarea claselor 
și identificarea subsistemelor. si să re RESO i 
m ; vitate trivială,. fü dintre cele mai dificile ` 
Identificarea claselor nu este o activitate trivialá, fiind una iiri: 
operaţii. JETESA că nu există o metodologie clară si unanim acceptată de reâlizate a ei Ia 


N 
H 


/ | | dr I5 


cartea sa [Boo91, pag.135], Booch afirmă: 


Clasificarea inteligentă este o muncă intelectuală grea şi se realizează cel mai bine 
printr-un proces incremental şi iterativ. 


Acţiunile recomandate pentru identificarea claselor sunt: 
1, Se consultă alte sisteme existente din același domeniu; 
. 2, Se discută cu experţi ai domeniului problemei; 
3. Se produce un prototip; 
4. Se studiază specificarea cerinţelor/propunerile de sistem: 
* se construiește o listă de nume; 
- se modelează obiectele fizice şi entităţile conceptuale; 
- se elimină sinonimele; 
- se modelează interacţiunea aparate/om; 
- se modelează valorile atributelor, nu atributele însele; 
- se Caută legături PARTE_A sau DE TIPUL; 
5, Trebuie să fie luate în considerare: E 
- necesitatea arhivárii informaţiei care se modifică; 
- comportamentul dorit al obiectelor clasei; 
- mai mult decát un atribut pentru un obiect; 
- cerinţele esenţiale precizate în specificarea problemei. 
v N 
Să considerăm exemplul următor: un sistem de supraveghere si conducere în timp real 
a activităţii unui nod de cale ferată, care are drept obiectiv automatizarea formării garniturilor de 
tren $i asistarea personalului din compartimentul de mişcare în elaborarea mersului trenurilor. 
Se pot identifica următoarele obiecte: S : 
- obiectul de bază este trenul, care poate ajunge de la punctul de plecare la destinaţie pe 
o anumită traiectorie (via, rută) şi poate transporta fie pasageri, fie bunuri 
(mărfuri); : 
- o rută este formată din mai multe segmente de cale ferată; fiecare segment uneşte două 
noduri de cale ferată; l 
- personalul de mişcare, care ataşează trenuri la rute; Y 
- personalul de tracţiune, care conduce locomotivele, şi rezolvă defecţiunile ce pot apare; 
- personalul comercial, care gestionează călătorii şi mărfurile transportate, precum şi 
vagoanele de pasageri şi marfá;  - I EN SO i : 
- poziţiile (renurilor la un moment dat, care se pot determina fie manual, fie prin 
instalaţii electronice de supraveghere. : : 


Modelul de clase ar conţine cel puţin următoarele: tren, nod de cale ferată, segment, rută, 

locomotivă, orar (mers al trenurilor), vagon, pasager, marfă. Se pot identifica trei categorii de 

iecte, după rolul lor în sistem; , i TE 

Limo - P biecte supuse controlului de cátre sistem. (program); . ele aparţin domeniului 
problemei: un tren în exemplul nostru este un astfel de obiect; i 

- obiecte de interfaţă; ele aparţin tot domeniului problemei, de exemplu impiegatul de 

mişcare; sistemul trebuie să interacţioneze cu impiegatul de mişcare: acesta 

apasă un buton, dând cale liberă unui tren, iar sistemul reacţionează la acțiunea 

impiegatului: trenul va porni; sistemul nu-l supraveghează pe aparsan OR 

- obiecte abstracte; ele aparţin domeniului soluţiilor, fiind inventate pentru a paroma 

bine sistemul, în ideea definirii funcționalități acestuia: segmentul de cale fe i 


este un asemenea obiect, 


Identificarea subsistemelor are ca scop reducerea complexităţii i 
este o mulţime coerentă de clase, fiind CEO Eeer Ee 
obiecte. Un subsistem poate fi derivat din: S E 

- o structură de asamblare; 

- o'clasă izolată; 

- 0 colecţie de clase care asigură o mulțime coerentă de servicii. 

,. o Subsistemele trebuie să fie slab legate între ele (respectándu-se principiul comunicării 
minime). În diagrame, subsistemele se reprezintă în chenare simple, iar legăturile între ele se 
reprezintă prin linii cu săgeți (arce orientate). 


Subsistemele descompun un sistem în subsisteme logice. 


În exemplul nostru, am putea identifica trei subsisteme: 
- mişcare: asigură buna circulaţie a trenurilor; 
- tracţiune: asigură locomotivele; -` UU. 
- comercial: se ocupă cu obiectele ce trebuie transportate . 


43.5.2. Precizarea structurii statice- 


Activităţile acestei etape au ca scop definirea claselor şia relațiilor dintre ele, adică: 
1. Stabilirea protocoluluide comunicație alclaselor; == -o | 
2. Identificareastructurilor de asamblare şi clasificare (ierarhiile de clase, construirea de 
-—. 7 clase ca ansambluri de Clase ete) — —— 9 o 
. 3. Definirea atributelor claselor şi a relaţiilor între clase. .— 


Produsele realizate reflectă activităţile enumerate mai sus, constituindu-se în prime versiuni 


pentru: ` SE EE EE S 
~ Ee Definițiile de clase; 2 — — e EE 
2. Diagramele de structuri de asamblare; ` — E ur e ue E 
3. Diagramele de relaţii între case 


4. Diagramele de structuri de clasificare. d E 
- Identificarea structurilor de clasificare are ca scop precizarea ierarhiei de clase. În 
proiectarea acestei ierarhii trebuie să se țină seama de următoarele reguli: à 


& ta 


1. Consideră fiecare clasă ca o generalizare > === > = —— EE 
- se poate descrie fiecare specializare cu atribute si operaţii diferite? 
-- deosebirea dintre diverse specializări este relevantă pentru scopul sistemului 
; 2 (aplicației) e coop ree EE 


De exemplu, pentru clasa Locomotivă putem avea ca elemente de discuţie: electrică, 


Diesel, sau cu aburi; putere dezvoltată; autonomie. ^. , 


2. Consideră fiecare clasă ca o specializare ut : IET 
` — se identifică comunalităţile claselor (atribute sau comportament comune mai 
multor clase); Tf Ns supera Y : 
- se pot grupa comunalităţile într-o superclasa? + ad 
- FRAU rezultată constituie o abstracţie cu înţeles bine definit? . ` 
- atributele şi operaţiile comune se pun în superclasă, iar cele specializate în 
subclase. n 3 p 


^ 


` Obiect Transpóriat- Marfa 


S Spre exemplu, pentru clasa Vagon putem identifica doi d 
$1 vagon de marfă. Atributele comune ale uA va ipm 


numărul de osii, tipul sistem de frânare sau 
comunalitàji; ele vor fi proprii tuturor vagoanelo: 
ale superciasei Vagon, care va avea doi descendenţi: 


endenţi: vagon de pasageri 
gon (de pasageri sau de marfă), ca de exemplu: 
viteza maximă permisă sunt ceea ce numim 
r, deci este natural ca să le considerăm atribute 


Vagon Vagon de marfă V; 
S agon de pasageri 
- număr de osii Superclasa: Vagon Superclasa: ip 
- üp sistem frânare ' - tip marfă - clasa (LILIIT) 
= viteză maximă - capacitate - tip (restaurant, de dormit) 


“3. Utilizează clase abstracte 
- superclasele ce nu au instanţe sunt CLASE ABSTRACTE; 
~o clasă abstractă poate: e 
- să lase unele dintre metodele sale nedefinite; 
- să nu aibă variabile de instanță; 
- scopul unei clase abstracte este să asigure un protocol standard de servicii 
pentru subclasele sale; ` : : 
- o clasă generatoare de instanţe care este subclasá a uneia abstracte trebuie: 
: -~ să definească metodele lăsate nedefinite în superclasa abstractă; 
- să definească reprezentarea datelor (atributele). 


- Clasa Vagon poate fi considerată cao clasă abstractă. O altă clasă abstractă aferentă 
exemplului nostru este clasa Obiect_Transportat, care are ca descendenţi clasele Marfă şi 


Pasager 


- Preţ transport .  “Superclasa: Obiect Transportat Superclasa:Obiect_Transportat 
(metodă abstractă) = ` SE 
- Prep transport -- = - Deet transport. 


- (metodă ce trebuie: definită). Ly (metodă ce trebuie definită) SE e 
- Identificarea structurilor de asamblare are ca scop studiul modului în care se compun 
"obiectele pentru a forma noi obiecte. Câmpurile (variabilele de instanţă ale) unui obiect pot fi la 
rândul lor obiecte. În acest fel, pe baza unor obiecte deja definite, se pot identifica noi obiecte, mai ` 
- complexe, aşa-numitele ansambluri de obiecte. Pentru identificarea structurilor.de asamblare, se 
recomandă urmátoarele: — — Sa d OE 


=- 1. Consideră fiecare obiect ca un pe E 
; - care sunt componentele obiectului? i Sa à 
. - sistemul trebuie să păstreze urma (să arhiveze stările anterioare ale) 
„obiectului? ` CH EEN 
- `- se poate descrie fiecare componentă prin atribute? ` 
-: 2. Consideră fiecare obiect ca o parte e : AN EY 
* în ce ansambluri intră obiectul? ` ` eed 
- ansamblurile sunt relevante.pentru sistem? Care este destinaţia lor? 
- cu ce alte obiecte se combină un obiect pentru a forma un ansamblu? 


1denti e i i elor claselor, 
„Identificarea şi definirea atributelor şi relaţiilor realizează definirea atribute 1 
localizarea acestora in ierarhia de clase deja definità, specificarea atributelor si identificarea 
relaţiilor care există între obiectele din diverse clase. ` 


NS 


1. Identificarea atributelor claselor presupune analiză şi alegere. Trebuiesc studiate 
specificaţiile cerinţelor; numelor care au fost stabilite în etapa de identificare a 
claselor li se asociază adjective, luându-se în considerare proprietăţile relevante 
ale acestora. 


În exemplele prezentate am identificat câteva atribute (câmpuri şi metode) ale claselor 
Vagon si Obiect, Transportabil. 


2. Localizarea atributelor în ierarhia de clase este extrem de importantă, având în vedere 
criteriul: 


4 


Informaţia despre un anumit lucru se (ine într-un singur loc. 


„Această operaţie nu este de loc uşoară, şi este greu de precizat o metodologie, deoarece unele 
criterii sunt greu cuantificabile (de exemplu, ce înseamnă se potriveşte cel mai bine?). Ca reguli 
generale se pot recomanda următoarele: d 

- dacă un atribut se potriveşte cel mai bine unui anumit obiect; el se va atașa clasei 
“obiectului respectiv, =- = 
- într-o structură de clasificare, un atribut se va ataşa 


ruct celei mai generale clase ce-l poate 
conţine. S SE : 


3. Specificarea atributelor este o. operaţie mai puţin complexă decât cele anterioare, ea 
cuprinzând: ^ — c LU E MATE EAT 

- descrierea fiecărui atribut; — = = -= SE - = | 

- precizarea diverselor fațete privind atributul: valorile posibile, domeniul lor, limite ` 
inferioare şi superioare, unităţi de măsură, precizie, valoare implicită, restricții 

legate de valorile altor atribute); - — .— =-  - E SS 

- identificarea atributele derivabile. . 


t 


4. Identificarea relaţiilor înseamnă determinarea modalităţilor în care obiectele se pot 
asocia. În capitolul3 am discutat tipurile de structuri de asamblare şi ordinele 
de multiplicitate ale legăturilor în cazul structurilor. de date (prezentate. în 
tabelul 3.3.1). Ele se prelungesc natural şi în cazul obiectelor, deoarece 
atributele formează o structură de date. Clasele ale căror obiecte sunt asociate 
` se conectează prin arce în diagramele de relaţii, iar pentru fiecare relaţie se 
stabileşte ordinulei de multiplicitate şi obligativitatea ci. EU 


Legăturile (relaţiile) există între obiecte. Ele sunt descrise printr-o asociere între clase 
-de obiecte. De exemplu, relaţiile de asociere între- clasele Segment, Tren, Vagon, Orar, 
Locomotivă, Mers se pot ilustra în diagrama din figură 03-15 — ccs ES 
. .Un tren circulă de la punctul de plecare până la destinaţie pe mai multe segmente; pe 
fiecare segment, componenţa să se poale schimba, ca şi locomotivele care-l tractează. Există un 
- mers al trenurilor, o planificare la nivel de an feroviar; trenul poale. circula pe baza acestei 
planificări, dar situaţia reală a parcursului (orarul trenului) poate diferi de la o zi la alta. 


D 


SR eR E e 159 


- Figura 4.3.1. Diagrainá de relaţii între obiecte 


5. După ce activităţile de mai sus au fost îndeplinite, urmează natural revizuirea 
definiţiilor claselor, acordându-se o atenţie deosebită următoarelor situaţii: 
- în cazul relaţiilor de tipul mai-multe-la-mai multe se verifică dacă este nevoie ca fiecare 
instanţă a relaţiei să fie descrisă cu atribute; dacă DA, se va defini o nouă clasă 
care să reprezinte relaţia şi se revizuieşte întreg modelul; z 
- clasele cu un singur atribut se elimină, mutánd atributul în clasa de pe nivelul superior - 
; al ierarhiei; x = Cu AN 
:- în cazul claselor ce conţin ca atribute obiecte din aceeaşi clasă, se verifică dacă acestea - 
nu se pot grupa într-o nouă clasă, care să aibă o altă relaţie cu clasa originală. 


_ Pentru exemplul nostru, urmează să completăm diagrama relaţiilor cu atribute şi operaţii. 
Se obţine astfel o completare a definiţiilor claselor si o rafinare a acestor definiţii, prezentată în 


figura 432. : 2 | 
De reparat |- 


: Dm. SE 
| Poziţie d 


. (m): (n) 


[Ehe 7 
.] Poziţie ` 


k 


Fibra 432; Atribute si relati între clase 


= 


- Figura 4.3.1. Diagramă de relaţii între obiecte 


5. După ce activităţile de mai sus au fost îndeplinite, urmează natural revizuirea 
definiţiilor claselor, acordându-se o atenţie deosebită următoarelor situaţii: 
- în cazul relaţiilor de tipul mai-multe-la-mai mulie se verifică dacă este nevoie ca fiecare 
: instanţă a relaţiei să fie descrisă cu atribute; dacă DA, se va defini o nouă clasă 
care să reprezinte relaţia şi se revizuieste întreg modelul; ` 


- clasele cu un singur atribut se elimină, mutând atributul în clasa de pe nivelul superior - 


al ierarhiei; Y 


s- în cazul claselor çe conţin ca atribute obiecte din aceeași clasă, se verifică dacă acestea 


nu se pot grupa într-o nouă clasă, care să aibă o altă relaţie cu clasa originală. - 


„Pentru exemplul nostru, urmează să completăm diagrama relaţiilor cu atribute şi operaţii. ` 
Se obţine astfel.o completare a definiţiilor claselor şi o rafinare a acestor definiţii, prezentată în 


fgura432. 55-00 0 


Loc Defectá | 
“| Descriere |. 
„De_reparat |- 


cap 


E LS urea 


Tecor | 


| Origine .. 
„Destinatie 


A — Y ` ; 
| Dată. 
= _|- Poziţie ` 
iai T Sapt ART II 3 Ev SC $ Se? 
EE . Figura 43.2: Atribute şi relaţii între clase. : 
"NM X > 
55d 
en : f f d CS 
f ^ 


4.3.5.3. Precizarea comportamentului dinamic 
a operaţiilor) 


(definirea proceselor si 


: Aşa cum am arătat anterior, programul este văzut ca o colecţie de obiecte care comunică 
între ele. După comportamentul lor, obiectele se pot clasifica în două categorii: active şi pasive 
Obiectele active, numite şi procese, sunt cele care au iniţiativa în program, pe când cele pasive 
execută ceva numai dacă obiectele active le tránsmit mesaje. 


Când un program este executat de către un procesor, el devine proces. Dacă programul 
are un caracter static (poziţia relativă a unei instrucțiuni în ansamblul instrucţiunilor ce formează 
programul nu se modifică), procesul are un caracter dinamic, pentru execuţia fiecărei instrucţiuni 
fiind necesară o anumită cuantă de timp al procesorului. În plus, o aceeaşi instrucţiune din pro- 
gram se poate executa de mai multe ori, în momente diferite de timp (de exemplu o instrucțiune 
din corpul unui ciclu), deşi ea în program apare o singură dată. Procesul este atașat unui proce- 
sor, care are acces la memorie (internă sau externă). 

Prin fir de control FC vom înţelege în continuare un proces. Într-o aplicaţie pot coexista 
mai multe procese (numite şi task-uri) care pot să apară şi să se termine dinamic. Aceste FC pot 
să se desfăşoare independent unele de altele sau pot să fie dependente între ele, numindu-se 
concurente. Un fir de control poate să genereze alte asemenea fire, a căror durată de viață 
depinde de dinamica execuţiei. În mod normal, fiecărui fir de control îi corespunde un procesor 

hard, deci concurenţa :reală are nevoie, de arhitecturi multiprocesor. Pe arhitecturile 
monoprocesor, această concurenţă a firelor de control este simulată. 
` Clasificarea făcută mai sus obiectelor în active şi pasive este făcută din punctul de vedere 
al concurenţei.-Obiectele active posedă fir de control propriu, pe când cele pasive nu. Dintre 
obiectele active, cele concurente posedă mai multe fire de control. Obiectele pasive pot fi 
secvențiale şi blocabile, ultimele existând doar într-un: mediu concurent. i 

Din punctul de vedere al relaţiei interobiecte, distingem obiecte client, furnizor şi agent. 


- Un obiect client utilizează resursele altui obiect, apelând operaţiile (prin mesaje) sau referind 


` starea lui; furnizorul este folosit de alte obiecte (i se trimit mesaje sau i se consultă starea), pe 


= 


când agentul are un statut mixt: pentru unele obiecte este client, pentru altele este furnizor; 


` agentul poate fi înţeles şi ca un obiect intermediar, o curea de transmisie. 


În etapa precedentă, obiectele erau privite din punct de vedere static. După ce se 
cunoaşte structura claselor, pasul următor trebuie să studieze obiectele în dinamica interacțiunilor - 
dintre ele. Prin urmare, activităţile acestei etape sunt: - ; 

- 1. Definirea comportamentului obiectelor active; 

2, Definirea operaţiilor claselor; — $ . xe 

3. Rafinarca claselor, structurilor de case si a relaţiilor dintre clase (dacă şi cât e 

necesar). : 


Produsele realizate specificá interacţiunile fiecărui obiect cu celelalte, precum şi maniera. 
în care se desfăşoară procesele. Vor rezulta: ` | : 

1. Diagrame de comunicaţie între obiecte; ES = 

2. Descrieri ale proceselor, prin diagrame de tranziție de stare; 

3, Definirea operaţiilor, în pseudocod sau altă notație echivalentă; 

4. Rafinarea în continuare a definiţiilor claselor. 


ii ă de la i ri fiecare obiect în 
ificarea operaţiilor pleacă de la specificarea cerințelor, Pentru hec: 
parte se dd Wer pe Es le execută şi se construieşte o listă de acţiuni de care este 
răspunzător obiectul. Apoi, se transformă fiecare acţiune într-o propoziție cu: 
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subiect (dacă se poate) predicat 
(cine face?) (ce face?) 


obiect 
(cui, la cine?) 


D D im 

În identificarea operaţiilor, trebuie avute în vedere cele două abordări complementare: 

- proiectarea la nivel de clasă: fiecare obiect se consideră izolat de celelalte şi se tratează 
ca o entitate autonomi; 

- proiectarea la nivel de produs program: fiecare obiect sè consideră ca o parte a 
MECANISMELOR necesare pentru satisfacerea cerințelor problemei. 


Proiectarea la nivel de clasă pune accentul pe responsabilităţile obiectului î ă 
INFORMAȚIE şi a asigura SERVICII. Întregul enano căt al SSC se considerh " 
dependent de starea acestuiă, prin urmare obiectul poate fi considerat ca o mașină cu număr finit 
de stări. Definirea operaţiilor (care vor stabili protocolul serviciilor oferite de clasă) trebuie să 
aibă în vedere următoarele SER 

- legături minime: minimizarea interacțiunilor şi interdependentelor dintre clase; 

- coerență: toate elementele unei clase trebuie să coopereze pentru a asigura o 

abstractizare bine definită; 

- suficienţă: trebuie să fie incluse toate operaţiile necesare clienţilor curenți ai clasei; 

- completitudine: trebuie să fie incluse toate operaţiile care ar putea fi cerute de clienții 

curenţi şi viitori ai clasei; 

` primitivitate: trebuie să fie incluse toate operaţiile ce oferă accesul la starea clasei. 


Prima dintre aceste cerinţe derivă din cele ale modularizării; celelalte sunt naturale şi 
oferă un ghid în ceea ce priveşte gama de operaţii care trebuie proiectate. 


Proiectarea la nivel de produs program ia în considerare interacţiunile cu alte obiecte 
(mesaje recepționate sau trimise). Pentru a identifica aceste interacțiuni, se consideră scenarii 
derivate din cerinţele problemei, scenariul fiind o secvenţă de evenimente care apar în timpul unei 
execuţii particulare a programului. Pentru fiecare scenariu, se decide cum se distribuie sarcinile 
asupra obiectelor şi se definesc în consecință operaţii adecvate pentru obiectele respective. Pentru 


ilustrarea traficului de mesaje între obiecte se folosesc diagrame de comunicare. 
Având în vedere ierarhia de clase (deja stabilită) se pune următoarea întrebare: 
La ce clasă C trebuie să ataşăm o anumită operaţie M? 


Răspunsurile diferă în funcţie de modul în care M accesează starea obiectelor. Există cel puțin 
ă situaţii: S : 3 
Lope SE accesul la starea unui singur obiect O; deci C va fi clasa obiectului O; 
b) M necesită accesul la stările mai multor obiecte şi O este singurul obiect la care M 
necesită accesul la starea privată a lui; C va fi clasa lui O; S ce ds 
c) M necesitá accesul la stările private ale mai multor obiecte din clase diferite; n 
această situaţiile acţiunile pe care M trebuie să le îndeplinească se po 
descompune, rezultând operaţii, ataşate claselor în cauză; fiecare EE 
accesa starea privată a obiectelor clasei sale, iar M va conţine apelarea acesto 


operaţii. 


La definirea operaţiilor unei clase trebuie avute în vedere tipurile de peret gane 
în 3.2.2. Reluând clasificarea fácută în contextul orientării pe obiecte şi ținând cont de ext 


colecţiilor de obiecte polimorfe şi de aspectele legate de concurenţă, distingem operaţii pentru: 


T. Go e să 
- construirea şi ştergerea obiectelor: constructori şi destructori ai claselor, ce trebuie 
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aibă în vedere modalități multiple de construire a obiectelor unei clase 
iniţializări de periferice, subsisteme etc.; i 

accesul şi moditicarea stării (publice şi private) a obiectelor; 

gestiunea colecţiilor de obiecte: adăugare, ştergere, selectare, modificare, iteratori 
(operaţii de parcurgere a colecţiilor), | 

conectarea şi deconectarea obiectelor, pentru realizarea ansamblurilor de obiecte: 

efectuarea de calcule sau specificarea de procese, implicând un singur obiect sau mai 
multe obiecte diferite; 

supraveghere a unui sistem, periferic, utilizator extern; aceste operaţii sunt specifice 
obiectelor ce interacționează direct cu programul. 


Specificarea unei operaţii se face în conformitate cu schema de specificare prezentată în 
figura 3.2.1. Specificarea unei clase înseamnă de fapt specificarea unui tip abstract de date. 


Definirea proceselor are în vedere agenţii. Fiecare agent se consideră ca o maşină cu 
număr finit de stări. Pentru determinarea stărilor trebuie luate în considerare; ` 
:- evenimentele externe pentru care agentul este răspunzător, de exemplu mesajele 
: receptionate de la alte obiecte; SE Pi 
- condiţiile în care obiectul reacţionează diferit la acelaşi eveniment sau mesaj. 

-Se va adăuga o nouă stare pentru fiecare combinaţie de valori a variabilelor de stare. 
Pentru fiecare eveniment, se vor identifica tranziţiile de stare, la nivel punctual: evenimentul va 
provoca modificarea valorii câtorva dintre variabilele de stare ale obiectului, dar acest lucru se va 

` discretiza într-o. secvenţă de tranziţii de o singură stare (o, asemenea tranziţie înseamnă 


modificarea unei singure variabile de stare). ` 


43.5.4. Evaluarea modelului. m 


Modelul realizat gradual în primele trei etape este supus evaluării, care analizează atât 
performanțele |exterioare. sistemului, detectate de utilizator (măsura în care cerințele sunt 
satisfăcute, necesarul de timp şi memorie), cât si aspectele ce (in de proiectare (legăturile dintre. 
clase, posibilitatea reutilizării). Activităţile proprii acestei etape sunt: — EUM 
5 1. Verificarea mecanismelor proiectate pentru à realiza cerinţele aplicaţiei; 

2. Verificarea coeziunii şi legăturilor; ^ ^ —- e 2 

3. Verificarea deciziilor de vizibilitate (dependenţele dintre clase); + 

4. Verificarea clasificărilor (pentru reutilizare); SE Aa sea ae ai 

„5, Verificarea performanţelor sistemului, — ` 


_6. Revederea (tuturor) aspectelor modelului pentru a le face cât mai adecvate. 


În această etapă nu. se. realizează -produse, conceptual noi, d se produc versiuni 
îmbunătăţite ale produselor realizate în etapele anterioare: - à 


43.5.5. Implementarea claselor 


"Ultima etapă a procesului de dezvoltare a softului este implementarea. În această etapă 
se A Olga ep E proiectarea fizică a claselor, adică transpunerea în limbaj de progra- 
mare (unul sau mai multe) a proiectului logic. Ca desfásürare, această etapă reproduce toate eta- 
pele precedente, la un alt nivel (cel virtual) de abstractizare. Activităţile proprii acestei etape sunt: 
: —. 1. Gruparea claselor de obiecte în module; ` | SES 
„2. Ataşarea proceselor la procesoare (unităţi de prelucrare). 


D 


ele 
H 
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stație Soana se repetă în interiorul fiecărui modul şi al fiecărei clase până când: 
„Nu mai există abstractizări primitive sau mecanisme noi, sau 
2. Clasele şi obiectele identificate pot fi implementate prin compunerea elementel 
software reutilizabile, ce se găsesc în biblioteci independente de aplicaţia dată, 


Produsele obținute sunt: 
1. Definiţii revizuite (rafinate în conti ale 
ipu ntinuare) ale claselor; 
2. Definiții de clase noi; 
3. Diagrame complete pentru module și procese. 


4.3.5.6. Nivele de abstractizare 


I entru orice pr odus pr ogr am putem distin € urmátoarele nivele ener ale de 
3 H g 


1. Domeniul probleméi, care confine obiecte specifice problemei de rezolvat; 

2. Interfața utilizator, ce operează cu obiecte meniuri şi videoformate; 27 

3. Gestiunea fişierelor, implicând datele” necesare aplicaţiei văzute ca obiecte, 

$ descendenți ai unei clase Storable Object; 

4. Gestiunea proceselor, ce referă obiectele active ale aplicaţiei şi sincronizarea lor; 

5. Structurile de date fundamentale: Jiste, stive, cozi, arbori, tablouri ş.a. 

6. Interfața cu perifericele: operaţii de UE la nivel fizic. SÉ 

În afara primului nivel, toate celelalte, proprii domeniului:soluțiilor, sunt opționale într-o 
aplicaţie, existenţa lor depinzând de caracteristicile problemei care trebuie rezolvată şi de soluţiile 

. de proiectare adoptate, Aceste ultime cinci nivele sunt cele care se pretează cel mai bine la 

reutilizare, existând numeroase biblioteci de asemenea componente, proiectate cât mai general. 
În interiorul fiecărui nivel, structurile de clase și relaţiile între clase pot induce ierarhii care 
generează nivele suplimentare de abstráctizare, ca de exemplu nivele de interfeţe grafice sau 
nivele de interfeţe specifice lucrului cu. tipuri speciale de date: reguli, predicate, expresii 
matematice, text etc. Ca regulă generală, orice nivel ce aparţine domeniului soluţiilor trebuie 


proiectat în ideeà reutilizării, ca şi cum n-ar fi specific numai aplicaţiei curente (deci cât mai ^ 


general posibil). Nivelele precizate formează o ierarhie de folosire, cu rădăcina în nivelul 
domeniului problemei. - 5 2 


Este evident că fiecare nivel se construieşte pe baza nivelelor ulterioare lui, deci pentru 

un nivel I nivelele J cu J> / vor fi nivele furnizor, I fiind nivelul client. Dacă la proiectare nivelele 
' se identifică şi se detaliază de sus in jos, plecându-se de la domeniul problemei şi de la cerinţele 
„precizate în specificarea acesteia, la implementare se respectă succesiunea inversă a etapelor. . 


Ierarhia nivelelor mai sus prezentată oferă şi un ghid în ceea ce priveşte componentele 
sau subsistemele unui produs program. Fiecărui nivel din domeniul soluţiilor ii vor corespunde 
module sau clase. Având în vedere ierarhia acestora, se pune natural problema comunicării între 


aceste nivele. Teoretic, comunicarea între nivele (deci între clasele şi obiectele definite în i 


respectivele nivele) se poate realiza cel puţin în următoarele moduri: 


- rin variabile de instanță (câmpuri): : è : ; 
olika definită la un nivel conţine și utilizează obiecte ce aparţin unor clase definite pe 
alte nivele (de obicei nivelele de sus folosesc nivelele de jos); un obiect din NI are un 
câmp care este instanţă à clasei Meniu definită în N2; 


- prin instanţierea claselor generice: 

un nivel instanțiază o clasă generică definită în alt nivel; 
exemplu de clasă generică: Lista[Element] din N5; 
exemplu de instanţiere: Lista[ Punct); 


- prin moștenire: CEST 

un nivel defineşte o clasă derivată a unei clase de bază definită într-un alt nivel: obiectele 
din N1 care trebuie să memoreze pe disc vor mogteni protocolul şi funcţionalitatea unei 
claseStorable Object din N3; în special moştenirea multiplă este utilă, ea permițând unei 


clase să moștenească protocoalele mai multor clase, definite pe diverse nivele de 
abstractizare; ; 


| prin mesaje: ` d : 
un Obiect de la un nivel trimite un mesaj unui obiect de la un alt nivel (de exemplu, un 
„obiect din N7 trimite un mesaj la un obiect din N3 pentru a face o salvare pe disc). ` 


Am afirmat că fiecare nivel se construieşte pe baza nivelelor următoare, existând nivele 
client şi furnizor. Se poate întâlni situaţia când o metodă dintr-un nivel furnizor apelează o metodă 
a unui nivel client (deci invers decât e normal). Acest lucru se întâmplă când client (nivelul 1, 2 
sau 3) redefineşte o metodă a unei clase derivate dintr-un container abstract sau polimorfic, 
furnizat de nivelul furnizor. Astfel, considerăm situaţia când la un nivel client definim o colecţie 
de date, derivată dintr-o- colecție. abstractă, de exemplu clasa numită, 

.. SortedCollection(PERSOANAJ, derivată din clasa generică SortedCollection[Element] definită ` 
` în NS. Pentru această colecţie trebuie definiți iteratori de tipul forEach, sau filtre de tipul first That 

„sau lastThat, proprii TD PERSOANA. În metodele clasei furnizor (din N5), care conţine definiţia 
clasei generice SortedCollection[ Element], vor fi apelate metodele forEach, first That, lastThat 
definite la nivelul client (N1 sau N2 sau N3). 56 PIX 

43.5.7. Machete şi diagrame xe 


În acest ultim paragraf vom preciza câteva dintre documentele ce formează documentaţia 

procesului de modelare orientată pe obiecte, şi care formează notația metodei. Aceste documente , 
suferă, după cum se constată, îmbunătăţiri succesive” pe parcursul „modelării. Structura lor, 

prezentată în continuare, corespunde etapei finale a modelării... ` d 


. Macheta de definire a clasei propusă de Civello si Mitchell este o rafinare a specificării 
unui TAD, ea conţinând următoarele informaţii: SE EE E 


Informația - N Explicaţie ` i 
Clasa: = > identificator ` AC EAN 
Responsabilităţi: + text (responsabilități/funcționalitate) ` 
Instanțe: listă, "mai multe", "nici una", "una" Ce 
Superclase: .  . listă de nume de clase . SC 

` Parametri: ^ — listă de pafametri (la clase generice) _ 

Servicii: ` ` ` lista declarațiilor de operaţii > = e 
' Componente: ` . lista numelor de clase şi obiecte cu indicatori de multiplicitate 
EE A GEES POLUM CIUS 

ibute;. « = „lista numelor şi TD pentru atribu : Ke 
Ss “lista relaţiilor cu alte clase, cu-indicatori de multiplicitate şi . 
+” optionalitate , SS i 
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. Furnizori: S 


listă de nume de clase 


x H J 3 
E secvenţial/blocabil/activ ` 
es: numele procesului 
Performanţe: 


comentarii privitoare la com lexitate: ti i 
A plexitate: timp, mem 
necesară, etc, P; SC 


Macheta de definire a serviciilor este la rândul ei o dezvoltare a specificării une 


Ea conţine: i operati; 
Informația Explica(ie 
Serviciul: nume clasă::nume operaţie 
Scop: : text i 
Categorie: NS constructor/destructor/accesor/modificator 
, Parametri formali: lista declaraţiilor parametrilor - 
Rezultat: SA nume de clasă sau tip 
Precondiţie: PDL şi/sau instrucţiune logică 
Acţiune: ` PDL sau analiză de caz sau cod program 
Postcondiţie: — - PDL şi/sau instrucţiune logică ` 
Concurenţă: - secvenfial/cu gardă/concurent/multiplu 
Performanţe: ` y comentarii privitoare la complexitate: timp, memorie 


necesară, etc. 

Diagrama comunicării între obiecte are ca scop evidenţierea mecanismelor necesare 
pentru a: îndeplini c Si funcție a sistemului sau a executa un scenariu dat. Punctul de start al 
scenariului este un eveniment extern sau un mesaj trimis unui obiect. Obiectul de start din 
diagramă esté cel care este responsabil cu detectarea evenimentului sau cu răspunsul la mesajul 
de start. Xu ; : 


Diagrama tranziţiilor de stare arc ca scop descrierea comportamentului obiectului. Fie- - 
care obiect este modelat ca o maşină cu număr finit de stări. Evenimentele pot cauza tranziții între 
stări, iar o tranziţie poate fi asociată cu una sau mai multe acțiuni. Evenimentele reprezintă puncte 
în timp, pe când stările reprezintă intervale în timp. Starea este abstractizarea valorilor atributelor . 
şi legăturilor unui obiect cu alte obiecte: În stări diferite, acelaşi obiect reacţionează diferit la 
acelaşi eveniment. ` E E SERE SS : 

Un obiect „pasiv poate executa o tranziţie, de stare. numai ca rezultat al unui mesaj 
(transmis de alt obiect). Când un mesaj M, care este parte a protocolului obiectului O nu are 
asociată o tranziţie pentru o stare S a obiectului, se va provoca o eroare de sistem la primirea 
mesájului M de către O (aflat în starea S). Similar, când un eveniment extern E pe care obiectul 
O este responsabil să-l detecteze nu are asociată o tranziţie pentru starea curentă S a obiectului, 
se presupune că operaţiile ce constituie interfața de intrare sunt responsabile pentru blocarea sau 
evitarea evenimentului E SE A 2 


Diagrama de modul conţine modulele şi legăturile dintre ele (marcate prin linii cu. 
săgeți). Un sistem mare conţine multe module, iar modulele pot fi grupate în subsisteme. - 


Diagrama de modul Ja nivelul produsului program trebuie să ilustreze numai legăturile între 
subsisteme. 4 


Din punctul de vedere al proiectării fizice, un modul este o componentă soft (pachet în 
Ada, segment compilat separat în C, C+ + „unit în Turbo Pascal). El poate conţine una sau mat 


multe definiţii de clase. Unit-urile Turbo Pascal ULoc, UPctS, UPctD, UCerc, USeg, UArc, UList 
prezentate la sfârşitul secţiunii anterioare sunt astfel de exemple, fiecare conţinând câte o definiţie, 

de clasă, Există însă si module ce nu conţin definiţii de clase (de obicei un modul de bibliotecă 

care este o colecție de funcţii, cum ar fi unit-ul UGraph din exemplul 4.2.8). Un modul poate 

utiliza alte module, existánd aga-numita dependenţă la compilare. Dependentele între module 
derivă în general din dependentele între clase. Spre exemplu, toate unit-urile UPctS $i UPctD din 
„exemplele 4.2.2 şi 4.2.4 folosesc unit-ul ULoc deoarece clasa Punct definită ín ele este o clasă 

derivată a superclasei Locaţie. 


“Într-un modul care conţine definiţia unei singure clase, diagrama de modul nu este 
necesară, Un modul se reprezintă printr-un dreptunghi (alb pentru partea de interfaţă, hagurat 
pentru implementare), în care operaţiile apar în chenare, iar câmpurile în chenare rotunjite la 
colțuri. = E 
Diagrama de proces ilustrează interconexiunile dintre procesoare si dintre procesoare 
şi periferice, fiind necesare când programul se execută pe o arhitectură multiprocesor. Se 
recomandă ca un procesor să se reprezinte printr-un paralelipiped, iar reprezentarea perifericelor 
este lăsată la dispoziţia proiectantului. În interiorul fiecărui procesor se specifică procesele 
afectate lui, 


m 


Dos o aei 


multe definiţii de clase. Unit-urile Turbo Pascal ULoc, UPctS, UPctD, UCerc, USeg, UArc, UList 
prezentate la sfârşitul secţiunii anterioare sunt astfel de exemple, fiecare conţinând câte o definiţie 
de clasă. Există însă şi module ce nu conţin definiţii de clase (de obicei un modul de bibliotecă, 
care este o colecție de funcţii, cum ar fi unit-ul UGraph din exemplul 4.2.8). Un modul poate 
utiliza alte module, existând aşa-numita dependenţă la compilare. Dependențele între module 
derivă în general din dependenţele între clase. Spre exemplu, toate unit-urile UPctS si UPctD din 
exemplele 4.2.2 si 4.2.4 folosesc unit-ul ULoc deoarece clasa Punct definitá in ele este o clas 
derivată a superclasei Locaţie. 

“Într-un modul care conţine definiţia unei singure clase, diagrama de modul nu este 
necesară. Un modul se reprezintă printr-un dreptunghi (alb pentru partea de interfaţă, hasurat 
pentru implementare), în care operaţiile apar în chenare, iar câmpurile în chenare rotunjite la 
colțuri. EN is ala 


Diagrama de proces ilustrează interconexiunile dintre procesoare şi dintre’ procesoare 
şi periferice, fiind necesare când programul se execută pe o arhitectură multiprocesor. Se 
recomandă ca un procesor să se reprezinte printr-un paralelipiped, iar reprezentarea perifericelor 
este lăsată la dispoziţia p 
afectate lui. 


roiectantului. În interiorul fiecărui procesor se specifică procesele 
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TIPURI ABSTRACTE DE DATE UTILIZATOR 


: Vom discuta în continuare proiectarea gi implementare 
utile în dezvoltarea de aplicaţii. en sunt: de precar ten he ardea 

- TAD Tablou Ordonat: 

- TAD String Extins; 

> TAD Ecran Extins; 

= TAD Utilitare; 

- TAD Videoformat; 

. - TAD Meniu Pull-Down. 


Tipurile enumerate sunt structurate ierarhic, pe másura complexitàtii lor. Unit-urilc 
Turbo Pascal care implementează aceste TAD. constituie un toolbox (cutie de instrumente 
deosebit de util în dezvoltarea de aplicaţii. ` 


SL. TAD TABLOU ORDONAT 


 Specificărea TAD Tablou Ordonat se bazează pe! TAD Tablou, mai precispe paan 
abstractă pentru TD tablou monodimensional, care cus rândul í ei referă Sege 
Bpuidi indicilor TI. 


A 


Specificarei SL L Tipul abstract simplu: TI 


Elemente: Indicii au că tip un DEE finit ital unui tip ordinal 8 liniar, numit tip d 
bazá al indicilor TBI (de obicei integer). ` CART 
- Structură: de ordine şi liniară. 
"Domeniu: definit de cea mai mică (ti), respectiv cea mai "mare d valoare (Is), in sens. 
5 relaţiei de ordine. 
S Operații: Fiind: un subtip al tipului subdomeniu, H mosteneste t toate operati acestuia. 


> E 542. Tipul abstract structurat Tablou 


Elemente: componentele tabloului aparţin tipului 7 TB, predzat 3 
- Structură: fiind precizat tipul indicilor TI, există.o. relaţie liniară definită pe d domésiut 7 1 
i cu valori în mulțimea componentelor used Verc indice îi aer c 
` componentă unică si invers); ; 
Operații: se pot defini: două Spot de bază: - 


Recall(A:Táblou; Am varv:TB) ` po. UU A NIRE [v-ABOc 
„Pre Mise IA S SEH Si 
CR tablou (ializa à JOE 
SE Post: v va conţine valontes componentei vis ia pă PER 
e Store(A/Tablou; î:TI, V:TB) SE a ce Sat {Ai 
Pre iară PEN E E 


Post: componenta de indice i din tabloul A va primi valoarea lui v. 


TAD Tablou Ordonat este o particularizare a TAD iniensional î 
elementele sunt memorate în ordinea teg a valorii a aaa În Cate 
ERA o is Gr GE într-o manieră simplă tabelul de indecsi pentru un fişier de 
ElementTablou) va EDEN două cat pari EE LEE 

- Cheie - câmpul cheie de tipul TipCheie; 

- NRREC - numărul înregistrării din fișier cu cheia Cheie. 

Se presupune că înregistrările din fişier au chei unice. 


` Specificarea 5.1.3 prezintă TAD ElementTablou, iar specificarea 5.1.4 prezintă 
Tablou Ordonat. A EAT (Us eun id 


Specificarea 5.1.3. Tipul abstract structurat E/ement Tablou 


; ; 

Elemente: Elementele componente sunt partea de identificare, respectiv adresa unei 
înregistrări dintr-un fişier. . | 

Structură: Se notează cu Cheie partea de identificare, respectiv cu NRREC adresa 
înregistrării, există o'corespondenţă unu-la-unu între fiecare identificator şi 
elementul component corespunzător (cheia este unică). 

Domeniu: Informaţia de identificare Cheie este. de un tip neprecizat, numit generic 
TipCheie, asupra căruia se pune condiţia să fie ordonat. Informaţia de adresă 
NRREC este de tip întreg. Domeniul tipului ElementT ablou, DET este văzut 

~ ca produsul cartezian al acestor două domenii ale elementelor componente. 

Operații: Relaţia de ordine definită pe domeniul tipului TipCheie induce o relaţie de 
ordine pe domeniul tipului ElementTablou definită prin operaţia MaiMic, 
precizată în continuare: Este singura operaţie care ne interesează, celelalte 
operaţii ținând de natura tipului de date TipCheie, neprecizat. : 


MaiMic(el,e2:ElementTablou):Boolean ` . QU CODES [ste 22) 
Pre e1,c2eDET. . — = , 
| Post: Dacă e1.Cheie < e2.Cheie | 
| „> atunci MaiMic (e1,e2) va fi True 
i . altfel MaiMic(el,e2) vafiFalse. ` ` 


Specificarea 5.1.4. Tipul abstract structurat Tablou Ordonat | ` 


je Elemente: componentele tabloului aparțin tipului ElementTablou, precizat. — ` 
l Structură; de ordine (moştenită de la ElementTablou) şi liniară (moştenită de la 


IRE Tablou). | 
EP CA Domeniu: se noteazá cu: jue RON RUND | à 
| qu - DimTablou  - dimensiunea maximală a tabloului, cunoscută la execuţie; 
| - Sfârşit - dimensiunea reală a tabloului (numărul de elemente memo- 
|! aS ; KE ERR el); Sem x RESET 
i ap AE - Contor - indicele curent al tabloului, de tipul TZ, culi = 1 şi ls = 
| ure ted uu esu ov oMaxint ee s ` 

„Spaţiu |o 7 adresa primului element din tablou. ` 


Operații; operaţiile acestui TAD sunt următoarele (în notație Turbo Pascal): \ 


i j 
|^ ^n uy i "s $ 
A 
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Constructor Init(N: Dew 
alocá un tablou cu N AME iniţializând cu 0 i i 
Pre: Tabloul nu este alocat, ; aepo ai 
Post: Se alocă spaţiu pentru N elemente; 
Dimensiunea reală şi indicele curent se setează pe 0. 
Destructor Done ( dealocă tabloul ) 
Pre: Tabloul este alocat. 
Post: Spaţiul de memorie afectat tabloului se eliberează; 
Dimensiunea maximală, reală și indicele curent se setează pe 0. 
Function Există( Var ET:ElementTablou; Var I:IndexTablou) : Boolean; 
( precizează dacă Eyes cu cheia ET.Cheie este memorat în EE ) 
Pre: Tabloul este ordonat. 
Post: Tabloul este ordonat; 


Dacă ET.Cheie există în tablou | 
atunci 
Există := True; 
i pue indicele elementului de tablou c cu cheia ET. Che 
e : 
Există := False ` 
* I este indicele pe care ar trebui să its un element de tablou cu cheia ET,CHEIE, 
SfDacă. 


Procedure Insereazi(Var ET: ElementTablou; Var Dublu,Dep: Boolean) 
( inserează elementul ET în tablou la locul lui (păstrând ordonarea tabloului) ) 
| Pre: Tabloul este ordonat. , - ; 5 
2X. Post: Tabloul este ordonat; i SE S7 
b Dacá Sfârşit = - DimTablou Dcum 
atunci Dep := True SE : 
Dacá Existi(ETJ) ROC cde S. ex 
atunci Dublu : = True Ae Ned S DRS SE 
"altfel —— E e iu ET este inserat în tablou 
Dep := False; ; Es 
Dublu : = False; 


Ki 


D BW SE cu o E spre e Stai EL allee din tablou, 
„ incepând cu poziţia I + 1 si pune pe ET în poziția I + 1, mărind 
RRR - cu numarul de elemente memorate în tablou. 
SfDacă. d gi SC ' 
SfDacă. | LAE RE zi 3 
Proced terge Var ET: ElementTablou; Var Găsit: EE 
E A z ca RCM CR EU ( sterge RR ET din CES 
Pre: Tabloul este ordonat. (ECCLE a : ` 
Post: Tabloul este ordonat; 5 2 ie o S Em ; 
Dacă Existá(ETI) VES E 


t deplasează cü o poziție Gp început DOR m din tablou, de la - 
~ indicele I până la ultimul element din'tablou si micşorează cu 1 
“numărul de elemente din tablon, ; 
altfel Găsit := False. | SE | 
SfDacă, jt 


Procedure Modifici(Var ET: ElementTablou; Var Gásit: Balea); 


PS Tebioül eas ord ot ( modifică elementul ET din tablou Sl NRR EC) ) 
Post: Tabloul este ordonat; 
Dacă Existá(ET,I) , 
“atunci s 
Găsit := True; - i 
* modifică elementul de pe poziția I cu valoarea lui ET. 
altfel Găsit : = False. 
SfDacă. Di, 
Function ` Caută(Var. ET: ElemehtTablou) : Boolean; 
{ caută un element cu rig specificată î în ET.Cheie } 


EE mt 


Pre: Tabloul este ordonat. 
Post: Tabloul este ordonat; d , ; ; : 
"Dacă Există(ET, D s POOR . 
` atunci ! [ 
* atribuie lui ET valoarea See de pe poata din tablou. | 
Caută : = True. TI REA c GË | 
altfel Cautà : — False. io e E AS e I ESEAS E 9 
SfDacà. pr ; ^ 
Procedure EE ET: ElementTablou; Var Dep: Boolean); ; ; 
bi incrementează Contor şi întoarce elementul de indice Contor : 
Cu apelarea EE produce p parcurgerea tabloului } : 
Pe Tabloul este ordonat. x è i Si 
Post: Tabloul este ordonat; : : : UR 
„Dacă Contor = Sfârşit EE s : E 
atunci Dep := «He. : OE SC E SE 2 
altfel Avo M ; EE : t 
t*Dep: = False; UE OA elem CSS D MUT : : 
* Contor se măreşte cu ds i ; : - f 
-* RET vafi elementul. de ES e podia Contor din tablou. = es ai S i 
SfDacà. rr j 3 x A " Y SN : os S [ 


DU Bes r heo ENS pA 


Function. SfársitT : B olean; ip sa 
rn e. True dacă indicele curent tal tabloului este egal cu EN 
rd em Nr cse Pireu A elemente din tablou } 


Procedure SetContor(T: Word); 3 i E Hu erm indicele ees - ES 


wCont Word; : 
Function on 9 Di intoarce valoarea indicelui curent al tabloului ) | 


Ti Ch x 
E Function . FirstKey : ipt eie; di intoarce S aloarea celei mai mici chei din tablou ) 


—” Wo 


Ti Cheie; d. 
^ e Function - Lea: ipf m „(întoarce valoarea celei mai mari chei din tablou : SS 


3e U ‘Ordered: ENEE 
SE i 1 intoarce False dacă informaţia de adresă nu este ordonată, ştiind că în yer. 


înregistrările nu sunt memorate în ordinea crescătoare a cheilor ) 


îi Soluţia, alocării ARNA, a tabloului, precizată à în specificatia 5.14, oferă o mai rare 
flexibilitate în exploatare. Vom considera o implementare a, TAD 
„ alocarea dinamică a die con 


“Tablou Ordonat ce va realiza 
siderat ca obiect. Acest lucru se realizează eec 


a) se declară tipurile de date: 


Tablit+ = Array[1..1] of ElementTablou; 
TabPtr =. ^ Tablll; 
IndexTablou = Word; 


b) cunoscándu-se dimensiunea dorită (notată DimTablou), alocarea zonei de memorie 
necesară se va face folosind procedura Turbo Pascal standard GetMem: 


GetMem(Spatiu;DimTablou* SizeOf(ElementTablou)); 5 


iar dealocarea se va face cu procedura FreeMem: 
FreeMem(Spatiu,DimTablou*SizeOf(ElementTablou)); 
pointerul Spaţiu fiind de tip TabPtr; 
€) accesarea unui element de tablou de indice I (1xI«DimTablou) se va face astfel: 
Spaţiul] ^ - o m or 
- Din punctul de vedere al reprezentării sale, TAD Tablou ordonat va conţine câmpurile | 
 precizateinspecificareaS.1.4. ^. 7 7 07 0. fa d 
: La implementarea TAD Tablou Ordonat s-au folosit facilitățile de programare bazată ` 
pe obiecte oferite de limbajul Turbo Pascal versiunea 6.0. Un astfel de tablou este o instanţă a. ` 
clasei numită Tablou. Definirea integrală a sa este conținută în unit-ul Liste, prezentat in - 
continuare. În implementarea operaţiilor de adăugare şi ştergere a fost folosită procedura stan. ` 
dard Move, iar operaţia Există a fost implementată folosind căutarea binară, ce exploatează faptul. - 


că tabloul este ordonat, reducând numărul de căutări. Remarcăm, de asemenea, particularizarea 
tipului cheii de acces, TipCheie, pentru care operaţia de comparare MaiMic este compararea 


obişnuită pe şiruri de caractere. ` 


"Unit Liste; e 00e Rue ye s o do 0 : 5 z - {TAD Tablou Ordonat} 

INTERFACE . "x d M C NC C 
Stró = String[6]; ` EE 
IndexTablou = Word; E US E HER SE SEN SE 
TipCheie — t6, EE e 


a 


— Mipinfo. — Word; 0259 506 c occ cep 
-ElementTablou = Record. — ^ = = - JUS ONES 
E "Cheie : TipCheie; Ec. Gu CP Ai E 
a ^. ;NRREC: Tiplnfo; ZR A 


jo. End; ZE Be 
! Tabl11 = Array[1..1] of ElementTablou; ` 
TabPtr = ^ TablT1; MESSER 


Tablou = Objet 707 o esce es SC 
"Dim Tablou,Sfârşit,Contor : IndexTablou; | m 
“Spaţiu: TabPtr; | —— m WES iS Ports 


Deéstructor Tablou.Done; `. 


Constructor Init(N:Word); 
Destructor Done; 


Procedure Inserează( Var ET:ElementTablou; 
Var Dublu,Dep:Boolean); 
Procedure Sterge(Var ET:ElementTablou; 
Var Găsit:Boolean); 
Procedure Modifică( Var ET:ElementTablou; 
Var Găsit:Boolean); 
‘Function Există( Var ET:ElementTablou; 
Var I:IndexTablou) : Boolean; 
Function Caută(Var ET:ElementTablou) : Boolean; 
Procedure Citeşte(Var ET:ElementTablou; Var Dep:Boolean); 
Function SfârşitT : Boolean; : 
Procedure SetContor(I: Word); 
Function ShowContor : Word; 
Function FirstKey : TipCheie; 
Function LastKey : TipCheie; 
Function UnOrdered : Boolean; 
End; ( Tablou Object ) 


MPLEMENTATION 


Constructor Tablou.Init(N: Word); SE USE Ee 
( alocă tabloul cu maximum N elemente şi pune pe 0 numărul de elemente şi indicele 
curent } S CH 
Begin  . S ; FVE . e 
DimTablou := N; ES 
Sfârşit := 0; , —— SC 
Contor :=0; M ` i x 
GetMem(Spatiu,DimTablou*SizeOf(ElementTablou)); 
-End; { Init} = SCH GE 


H 


D 


( dealocă tabloul şi pune pe 0 numárul maxim şi efectiv de elemente şi indicele curent 
FeecMem(SpatiuDimTablou*SizeOfElementTablou)); 

DimTablou := 0; . E 4 SS 

End; ( Done ) 


Function Tablou.Existá(Var ET:ElementTablou; 
Var I:IndexTablou) : Boolean; C 
{ dacă elementul cu cheia ET.Cheie există în tablou . 
arunci intoarce True, l EEN Ze 
2 False, : 
quee poziţia pe care ET o ocupă sau ar trebui s-o ocupe în tablou 
metoda implementată este căutarea binară | 
MATS NER Chet 
Stânga,Dreapta,Mijloc : Integer; . 
Găsit ; Boolean; 
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Begin 
FN (Sfârşit = 0) Or (ET.Cheie < Spațiu ^ [1].Cheie) 
; hen 
‘Begin ` 
I:= 0; 
| Existá: — False 
End 
else If ET.Cheie > Spațiu A [Sfârşit]. Cheie 
then Begin 
l: = Sfârşit; 
, Există := False 
End' 
else : 


Begin 
Stânga : = 0; 
“Dreapta := Sfârşit +1; 
Găsit : = False; 3 
(«2 While (Dreapta e Stânga > DA And (Not Găsit) Do 
Begin . 
Mijloc : = (Stânga + Dreapta) Div 2; 
-If ET.Cheie < Spaţiu” [Mijloc]. Cheie ^ 
then Dreapta : = Mijloc 
else If ET.Cheie > Soia Z Mijloc], Choig 
then Stânga := Mijloc 
else Găsit := True; 
End; - «* 
If Găsit then I : - Mijloc 
else ls Stânga; el E 
“Există : = (Güsip e KZ y 


End; 
End; { Există. id Tablou - CautăreBizară ) NL ae VAN 


Procedure Tablou. Citeste(Var ET: ElementTablou; Var Dep: Boolean); S 
{ întoarce elementul de pe poziţia curentă a indicelui — ` 
si incrementeazá indicele curent, dacá nu s-a ajuns 
la sfârşitul tabloului; altfel, pone RP pe True px 


Begin. S 
If Contor = Sfârşit ; Wee E Lud 
thenDep:- True D R e e 
ele ceu uer E S 
Be ; d SE 
; Ren. : = False; De E e 
v Inc(Contor); ^. 5 CA. 
IET = Spaţiu ^ [Contor] | PEA ns 
End > : E d 


End; 1 Citeşte E Dee : A 


| Function Tablou. Caută(Var ET: ;ElementTablou) : Boolean; 


dacă ET.Cheie există în tablou 
; atunci întoarce e şi completează ET. Info - 


altfel î DEE False ) 
"Var 


I: IndexTablou; 
egin 
1f Existá(ET,I) 
then 


Begin 
Caută : = True; 
ET := Spaţiu ^ [I] 
End 


else Caută : = False; 
End; ( Caută ) 


Procedure Tablou.Modifică( Var ET: EL emieniTablou; 
` Var Găsit:Boolean); ~ 
{ dacă ET.Cheie există în tablou ` 
atunci modifică elementul găsit la valoarea ET 
` altfel nu face nimic ) 
Var 
I:IndexT ablou; s 
Begin 
Găsit := Există(ET); 
If Găsit 
. “then Spațiu ^ [I] = ET; . 
“End; ( Modifică ) 


Procedure Tablou.Sterge(Var ET: GEES 
Var Găsit:Boolean); 
( şterge elementul ET din tablou, dies ordonarea acestuia jc 


Var 
LJ: IndexTablou; SCH SE SEH 
„Begin ` ` | S : SCH 
Găsit := Există(ET, D; Ee e 
Af Găsit 
then 
Begin ` vet E ` : E 
:-ForJ:-1to o Sfârşit Do N 
Move(Spatiu "+ 1)Spaiu^ Usenet) 
; Decr: S | 
End t Şterge E X e M : REO 


ziele ET mentio SS S S gero es 
Var Dublu,Dep:Boolcan); i 
A inserează elementul Eri int abog păstrând Seier acestuia ) 
- Var =. E SUN. : ` 
SH IndexTablou; - i SENN EN 
K Sfârşit = = DimTablou Lii NM UR 
then Dep:= Trué ` S 
else H Een ET) 0o Cer 


- 


A 


then Dublu : = True 


else 
Begin 
Dublu.: = False; 
Dep : — False; 


For J : = Sfârşit Downto I + 1 Do 
Move(Spajiu ^ [J],Spatiu ^ [J+ 1], 
Size OR ElemeLtlablou)V. 
Inc(Sfársit); 
Spațiu "+ 1]= ET 
End 


End; { Inserează ) 


Function Tablou. SfârşitT : Boolean; 
Begin : 
Sfárgit T :: = Contor! = Sfârşit; 
End; H SfársitT ) 


: Procedure Tablou. SetContor(I: Word), - 


Begi 
Contor : = I-1 EE : 
End; ( SetContor H SE 


EE Tablou: ShowContor : Word; 
Begin 2 
ShowContor : = Contor + Us 
End; i ShowContor jus 


Function Tablon FirstKey: TipCheie; 5 up 


Begin ` 
FirstKey := Spaţiu” S X Cheie 
End; { FirstKey js E 


Function Tablou. Lee? TipCheie; S S 
Bee 


End; ( LastKey ) 


Fu tion Tablou. UnOrdered: Boolean. i 


LastKey : = Spaţiu ^ [Sfârşit] ‘Cheie ; SE EE 


! 
H 


( Sfârşit Tablou ) 


„4 Setare Contor } 


z 


{ Valoare Contor } 


$E z Te SS 
„A Cea mai mică cheie ) 


"i (a Cea mai mare cheie ) : 


{ verifică dacă SE sunt itque în ser în în ordinea cheilor j 


Var 


E,Dep: Boolean: E ins SS SE 


ET: gelo Ep 


t caror); 
| . E:-False; 


Repeat SCH 
SE e ); 
Contor < Sfârşit ^ — 
L E: EET. NRREC > > Spin [Cor YN NRREC; 


` - {poziționare pe primul element] - 
3 See de parcurgere secvenţială) 


Until E or Dep; 
EM el E 
nd; ( UnOrdered | 
End. ( Unit Liste ) } 


În implementarea de mai sus, TipChei ificá ifi i 
1 : ; TipCheie este String[6]. Modifi i 
de date, în conformitate cu tipul cheii pentru un anume ri se GE 
adecvată. Singura restricţie impusă asupra TD TipCheie este casă posede operaţiile de comparare 
n cazul mai general, când TipCheie ar fi structurat (mai mult, el însuşi un TAD), ar trebui să 
posode operaţii de comparare. În această ultimă situaţie, corpul funcției Există ar trebui modificat, 
ocuind operatorii relationali (' —'; >") cu operațiile de comparare proprii tipului în cauză. 


5.2. TAD STRING EXTINS 


er Secţiunea prezentă şi următoarele conţin exemple de tipuri abstracte de date, ce se con- 
'sutuie în ceea ce am numit cutie dé instrumente, toolbox în limba engleză. Din raţiuni de spaţiu, 
vom renunţa la specificarea abstractă a TAD prezentate, rezumându-ne la explicaţii minime. 
Considerăm că autodocumentarea textului sursă este suficientă. 7 


Limbajul Turbo Pascal conține tipul predefinit String, dotat cu operații de manipulare 
a şirurilor de caractere şi de conversie între String şi tipuri numerice. În acest TAD am prevăzut 
operaţii noi pe şiruri de caractere, care se pot împărți în 3 clase: - 

- conversii String - numere; / 

- conversii numere - String: 

- operaţii noi pe tipul String. . 

> Prima clasă conţine procedurile StrToInt, StrToWord, StrToLong si StrToReal, cu 4 

parametri: S (String) si Len (Integer) de tip IN (parametri de intrare), respectiv / (sau R) 
(Integer, Word, LongInt sau Real) şi E (Boolean), de tip OUT (parametri de ieşire). Semnificaţia 
lor este următoarea: - = i carat : 


S - şirul de convertit la nümár; - et 
Len - cáte caractere din gir se iau ín considerare; 
. (R)- numărul rezultat; Í 
"E - me dacă conversia s-a putut face, 
False în caz contrar. 


Am considerat necesară scrierea acestor proceduripentru situația în care şirul de convertit conţine 
spaţii la sfârşitul său. În această situaţie, procedura standard Val nu furnizează rezultat corect, ea 
presupunând că în şirul de convertit cifrele sunt aliniate la dreapta. : : 


A doua clasá de operaţii conţine funcţii de conversie a valorilor numerice la şir de 
caractere: StrI, StrW, StrL, StrR. Am considerat necesară scrierea ácestora pentru o exprimare mai 
elegantă a expresiilor ce conţin şiruri. Funcţiile realizate au doi parametri: 

I(R) - numărul de convertit (Integer, Mord, Longlnt sau Real) si 
L - lungimea ín caractere à stringului rezultat. Ee Aun 
În cazul conversiei unui număr real, mai apare încă un parametru, De - numărul de cifre zecimale. 


Toţi parametrii sunt de tip IN. 


/ 
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Uu 


E: 


à 


Ultima clasă de operaţii conține noi funcții de luoru cu şiruri de caractere, după cum 


urmează: 


Trim(S:String) STEE caracterele din S mai puţin spaţiile de | 
SPC(N:Byte) întoarce un şir de N spaţii; Prepared citu 
ExtS(S:String; N:Byte) întoarce un şir de lungime N, construit din şirul S astfel: 
dacă Length(S) = N atunci ExtS : = S sfd 
dacă Length(S) < N atunci ExtS := S + SPC(N-Length(S)) sfd 
dacă Length(S) > N atunci ExtS : = Copy(S,1,N) sfd 
FillS(Ch:Char; N:Byte) întoarce un sir N de caractere Ch. 


Gees SE D este făcută în unit-ul UString, prezentat în 
continuare. ` 


Unit UString; Seu : (TAD String Extins) 
SIS 
Procedure StrTolnt(S:String; Len:Integer; SE 
Var I:Integer; Var E:Boolean); , gi z . 
Procedure StrToWord(S:String; Len:Integer; UR Or ES 
Var I:Word; Var E:Boolean); e 


Procedure Sela ont: String; LeniInteger; ` 
Var I:Longlnt; Var E:Boolean); 


} Procedure StrToReal(S:String; Len:Integer; 2 e 


Var R:Real; Var E:Boolean); 
Function StrI(LL: Integer) : String; RE 
- Function StrW(I:Word; L:Integer) : String; ` 


* Function StrL(I: LongInt; LInteger) : String; ` — SE 
- Function StrR(R:Real; L,D:Integer) : ms eeu SES 


és 


-. Function Trim(S: String) : Sting `: RN EN. 
* Function SPC(N:Byte) : String; E VEU Me 
" Function ExtS(S:String; N:Byte) : Sting ` , 


Function FillS(Ch:Char; N:Byte) : String; S SE | 


. Implementation 


A: 


„ Procedure ElimBlk(Var s: String); ER 
{ Mută spatie dela HESS B incepu în sil s id > 


L: Byte; - ; SCENE K 
If S[1] EE EE e i X 
SEL 2" do | 


Pre. L,1); 
Sls. S 


End; ML Mas. 
End; ( ElimBlk ). e MA 
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RI RE UNT a) E 


we 


Procedure StrTolnt(S:String; Len: Integer; 
Var I: Integer; Var E:Boolean); 
{ Transformá S = şir de Len cifre în intregul I. 


E; = True, dacă conversia s-a făcut cu mica 
Var 


J : Integer; 


egin 
ElimBIk(S); 
EE 1,Len),l,]); 


= (J = 0) and (Abs(I) < = Mann); 
End, ( StrTolnt ) 


Procedure Su ToWord(S: String; Len:Integer; 
Var Word: Var E: Boolean); 
( Transformá S = şir de Len cifre în întregul fără semn I. 


E: = True, dacă conversia s-a făcut cu succes ) 
Var 


T Integer; 


(S); | 
Val(Copy vea) 14); 
= U = 0) and (I < = Maxint*2) and (I > = Qi 
End; ( StrToWord Ee 
Procedure StrToLong(S:String; Len:Integer; 
Var ELongInt, Var E: Boolean); . 
( Transformá S — sir de Len cifre in întregul lung L 
E: = True, dacă conversia s-a fă ăcut cu succes J' 
Var 
J : Integer; - 
Begin 
vac RE | 
o n) 
= id 0): and (Abs). «s SE 
Ea, ( StrToLong ) um 
Procedure Stu ToReal(S: See Len:Integer; 
i Var R:Real; Var E: Boolean); 
Sch Transformá S = sir de Len cifre in numárul real R. 
E: = True, dacă conversia s-a făcut cu sücces ) 
Var SH DNAN 
J: Integer; ` i i 
‘Begi 


CAT > 


DE 


End; ( StrToReal ) 


Function Strl(,L: Integer) : String; 


A Transformă întregul I într-un şir de L cifre ) 
ar 


S : String; 
Begin 
S SEDES): 
Stri := S 
End; (Sul) , 
Function StrW(: Word; L:Integer) : String; 


A Transformă întregul fără semn I într-un şir de L Los } 
ar 


S : String; a j 
Begin SIDES ; EE 
Su(EL,S); ' ` 
SuW:-S ZA 
End; | SNC 
Function StrL(I: Longlnt L: Integer) : „String; 
'{ Transformá întregul lung I într-un sir de L cifre E 
Nan s.s 
S : String; 
"Begin ` ` 
Str(EL,S); ` EE 
'StrL:= S, BCE 
End; ( SuL ) ; 


vie ` CY » 


Function StrR(R:Real; L,D: integer) Stii qe MT și 
( Transformă realul R într-un sir de L cifre ~ SE kid 
din care D sunt penia: parten ixi. ju. 


 SURLD;S); pu E 
StrR:=S . ABD C E TEM UE 
‘End; (SuR] E SE EE 


Funcion Trim(S: Soin Sep 
At intoarce eun S din care s-au Venit isi v 


While tt ZO EE 
 DeletetT-LengthtT H EE SE 
tă Trim: x ` ' f. 2 T Y SCH SCH io ` ^x 
` End; (Trim] | : ; UICE S : 
tion SPC N:Byte) : 'Stribg; 

dem un gir compus is din. N spa 3s 

JM y j Ge E j ji a 

T: String; - E Ais 


For I: "Aren? K: Ue 
SPC := EE 


End; ( SPC } 


Function ExtS(S: String; N:Byte) : String; 


{ ner sau tende lungimcă şirului de caractere la N ) 


If Length(T) >N 
then T : = Copy(S,1,N) 


SE While Length(T) < N Do T:- T Eé 


End; (Es ) 


Function FillS(Ch: Char; N: Byte) : Eine ; f e 
{ întoarce un şir de N caractere Ch ps SE 


Var 
Aux: String; $ ALME Aa 
I : Byte; : : 
Begin : : x 
Aux:=”; AN ; 
Fort: Hd Aux; Aux + Ch : e 
FillS : = Aux x 
End; ( FillS ) ; 
End. ( Unit Usma} TUI D 


53. TAD ECRAN EXTINS E A E A A R d 

Pentru realizarea de meniuri ŞI i de videoformate- ecran (in mod text), sunt necesare o . 
serie de operaţii neincluse in unit-ul Crt. Programatorii Pascal (Turbo Pascal) au cunoştinţă de 
existenţa unor module (unit-uri), distribuite liber (freeware sau shareware), care conţin astfel de 
operaţii evoluate cu ecranul calculatorului, la nivel de text sursă. TAD pe care-l prezentăm în 
continuare a fost inspirat de un astfel de pachet de unit-uri numit TOP ( Turbo Override Package), 
elaborat de firma Nescatunga Software. din S. U.A. Noile operati Previous. se > împart în ` 
următoarele categorii: ` 

- operaţii la nivel fizic; 5 

- operaţii 'estetice" si cu rol de informare; 

- citiri de pe ecran; 

^- scrieri pe ecran. 


RES 


Puma categorie de operaţii EE serviciile î SE 10 si contine: 
HideCursor - ascundere cursor; ` : ; 
, ShowCursor — afigare cursor; ` | x i / 
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BigCursor  - cursor mare (dreptunghi); 

LineCursor - cursor linie; 

ReadFromScr - citire din memoria ecran, de la coor 
Len de caractere precizat. 


donatele (X, Y) precizate, un număr 


A doua clasă de operaţii completează cele existente în unit-ul Crt: 


S SetColor(F,B) - seteazá culoarea ecran la F cu fondul B; 
y S TCU. - Nan un semnal sonor; 
riteMany hum) - scrie pe ecran Num caractere Ch începând de ziţia X, Y; 
WriteSt(S,C,L) - scrie pe ecran stringul S începând cu coloana C linia S: 
GetCh(C,L) - citeşte de pe ecran din poziţia (C,L) un caracter; 
PutCh(Ch,C,L) - scrie pe ecran la poziţia (C,L) un caracter Ch; 


ReadAKey (Ch,FunctKey) - citeşte o tastă intorcánd caracterul in Ch $i punánd FunctKey 
: pe True dacă s-a apăsat o tastă funcţională; 

MessageLine(M) ` `  — afişează stringul M pe linia 25 a ecranului, . 

PickLine - afişează pe linia 24 mesajul informativ: 


H 


SELECTARE ` . Ret= Modificarecimp  Esc=iesire ; 
ModiLine : AUS - afişează pe linia 24 mesajul informativ: 
MODIFICARE Ret = Terminare modificare 
A treia clasă de operaţii realizează citiri de pe ecran, de la coordonate precizate. Ca 
principiu, este vorba de fapt de editarea unei;zone ecran, în care există deja informaţie. Zona în 
care se face editarea are alte atribute video decât restul ecranului, şi este permisă folosirea tastelor 


funcţionale, a căror semnificaţie este urmátoarea: - 


ESC. - abandonarea editárii şi refacerea. conţinutului iniţial; ` 


RETURN - terminarea normală a editării; S Se 
INS - comutator inserare (cursor mare) / suprapunere (cursor linie) 
DEL : * şterge caracterul de pe poziţia cursorului ` As 


BACKSPACE . - şterge caracterul de la stânga cursorului 

CTRL/BACKSPACE  - umple zona cu spaţii; n 

SĂGEATĂ STÂNGA  - avans cursor stânga un caracter; ` 

SĂGEATĂ DREAPTA- avans cursor dreapta un caracter; 

HOME - poziționare pe primul caracter din zonă; 

END `- poziţionare pe ultimul caracter din zonă. ` : 

ingerea limitelor zonei (primul sau ultimul caracter) provoacă un semnal sonor. De asemenea, 

Ge unui,caracter dn (neconform cu tipul datei care se editează) provoacă un mesaj 
de eroare. Operaţiile din această clasă se împart în două subclase: : ; 


— 


- de tip funcţie: A FUE UTE 
d $ i etStr(cJJen:Integer) : String; ` DEN à „citire string; 
dcus E pe euntis : String; „citire string (numai litere mari); 
Function GetInt(cJJen:Integer) : Integer; IRAE citire intreg pe 2 octeți; 
Function GetWord(c,l,Jen:Integer) ` Word; „citire întreg fără semn pe 2 Sete. ` 
Function GetLong(c)Jen:Integer) : Longint; citire intreg pto: E 
Function GetReal(c,l Jen,de:Integer) : Real; ci ; 


` 


Function AskString(M:String; c,lJen:Integer):String; 


183 


afişarea mesajului M şi citire string, zona de citire fiind capătul mesajului; 


- de tip procedură: ! 
dee :String; cJ: Integer; Var /:Integer); 
afisarea mesajului M si citire întreg /, zona de citire fiind capătul mesajul 

socat e AskWord(M:String; c: Integer; Var Z: Word); E y E 

afigarea esa ului M şi citire întreg fără semn /, zona de citire fiind capătul 

mesajului. 

Parametrii c, / şi len (de tip IN) reprezintă coordonatele ecran, respectiv lungimea zonei în care 

se face editarea. Din punctul de vedere al implementării, toate operaţiile din această clasă 
apelează funcţia internă EditField, care are antetul: 


& 


Function EditField(C,L,Len:Integer; Tip:Char) : String; 


$i care, la rándul ei, apelează, între altele, procedura ValidCh ce realizează validarea formală a 
Dread introduse in conformitate cu caracterul Tip ce specifică tipul câmpului (/ = întreg, 
= real, C= string). Ultimele PED proceduri meane sunt interne, 


A patra clasă de pereți realizează scrieri pe ecran, în zone precizate (coordonate, 


lungime şi, în cazul numerelor reale, număr de cifre zecimale), pentru TD numerice predefinite: 
- integer, word, longint şi real. Antetele Se sunt: . : 


Procedure PutInt(C. LLen: Integer); 

` Procedure PutWord(C,L,Len:Integer; I: Word): 
Procedure PutLong(C,L,Len:Integer; /:LongInt); ` de 
Procedure PutReal(C,L,Len De:Integer; R: Real); SS ZS 


Implementarea. completă a a operatiilor. descrise éste dată î în unital UScreen, prezentat 
în continuare. În partea sa de interfaţă sunt date codurile culorilor, respectiv tastelor funcționale 
folosite. Hupimenteres operaţiilor foloseşte operaki din unit- ul UString. 4 


Unit UScreen; ultor. exem PESE SE SSE | (TAD Ecran Extins} 


"INTERFACE. 5 ^ 
Uses Crt; NIRE 


Procedure Hide Clear m z ISSN UE se 
- Procedure ShowCursor; . GE A 

Function Readkromsci( SY Lei: Integer) : Sing ` HOS 

Procedure SetColor(F,B: Integer: CN LE 

Procedure Beep; - En 

Procedure WriteManyCh(Ch: Char; XX Num: nege; - Side 

Procedure WriteSt(S:String; cl: Integer); SRM RR ENSE Sis NOS 

Function GetCh(c,l:Integer) : Char; O RA : ux 

Procedure PutCh(Ch: Char; cj: Integer); ` SN SS 

Procedure ReadAKey(Var Ch:Char; Var FinérkeyiBocisa) 

Procedure MessageLine(M: String); ` t 

Procedure PickLine; ` 

Procedure ModiLine; 

Function GetStr(c,l, Pure String; A 

Function GAREA EES "String; AN 


Function Geünt(c,llen:Integer) : Integer; ' 
Function GetWord(c,llen:Integer) : Word; 
Function GetLong(c,l.len:Integer) : Longlnt; 
Function GetReal(c,l,len,de:Integer) : Real; 
Procedure AskInt(M:String; c,l:Integer; Var I:Integer); 
Procedure AskWord(M:String; c,l:Integer; Var I: Word); ` 
Function AskString(M:String; c,llen:Integer):String; 
` Procedure Putint(C,L,Lea,l:Integer); 
Procedure PutWord(C,L,Len:Integer; I: Word); 
Procedure PutLong(C,L,Len:Integer; I:Longlnt); 
Procedure PutReal(C,L,Len,De:Integer; R;Real); ' 


Const  - 
'ColorF1'= Yellow; 
ColorB1 = Blue; 
ColorF2 = Black; 
ColorB2 = LightGray; 
ColorF3 = White; 
ColorB3 = Black; 
ColorF4 = White; 
ColorB4 = Red; . 


S { coduri de culoare din unit-ul Crt E 


LeftArrow = #75; OST us ( coduri de taste funcţionale ] 
Ripht^rrow = 377; ; EE mu : 
UpArrow 2372; -.- SE : MO EU 
DownArrow. = #80; . SN Sa AEN ESL RM E SA 
InsertKey = 482; —— = n cO Ea Rp pU da I 
DeleteKey = #83; ; SENS Qe Sanie, OE 
EnterKey 2153; . P LIS SA At ea 
EscKey ` — 427; : Spa ca EE at Pee MANNA EE 

- BackSpKey: = EE a CR M CS 
CulBackSp = £127; ; AU d EU e ^. NOR ACCES 
HomeKey = #71; EE 

EndKéy — 6 EE 

V PgDn. EE 


4 369 E Ge E * RAM X SE B i x S R 
EE EE 
4 XCh: Char; DENS ESSERI ‘=. f păstrează ultimul caracter citit de la — 

p 5 stastáturá, care este necesar pentru - 
S EE E EE comunicarea între diversele proceduri } 
+ IMPLEMENTATION... $050 mor da ; 


R: Registers; - ; 


SaveAttr ` Byte; VES et pia T S SE XY 
"HeaderStr: String; 7:7 ZU oM 


Um A 
X | ! i : 


st 


{ ascunde cursorul ) 
300; : 
Intr($10, R); À } 1 
RCX:= R.CX or $2000; : zu 
RAN : = $0100; : ; 
Intr($10,R); 
End; { HideCursor ) 


Procedure ShowCursor; 


egn 
RAX := $0300; 
Intr($10,R); 
R.CX : = R.CX and $DFFF; 
R.AX : = $0100; ; 
Intr($10,R); 

End; ( ShowCursor ) 


( afişează cursorul ) 


Procedure BigCursor; ` S: ; { cursor dreptunghi } 
Begin ; e SE SE 
R.AX := $0100; 
I£ (Mem][0000:1040] and 48) <> 46. ; 
then R.CX : = $0107 : 3 S ` 
else RCX := $010D; ` =~ - EE 
Intr($10,R); .- inue Bc e 
End; ( BigCursor ) SN . EE 


Procedure LineCursor; RE e ta aa ` „4 cursor linie ) 

Begin E e 

R.AX : = $0100; 

If(Mem[0000:1040] and 48) <>48 — . EN DEI cc Re 

then R.CX : = $0607 b e m ca 

else R.CX := $0COD; SE uS. ` i 

Intr($10,R); - > um Sa 
=i { LincCursor] | S : ae Cc 


"ucro ReadfronSo(X Y Leer Střing; 
Var .- 1 citire din memoria ecran, dé la coordonatele } 
i TempStr : String; . S E SO si pe luaginea Len 
ILL : Integer; -` NS Pan MCA EC EN : : T 
SA S s YS 5 See 
For D: = 1 to Len do S NON ASQ SEN 
Begin ` cU NE SEDEM E ` 
GoToXY(X 4 II-Y): c NBN : 
.R.AX:-— $0800; ` 
R.BH : m D ; 
Intr($10 Y Ge 
Tempull: = Car) | ` E 
End; AN 


ShowCursor; 

TempStr[0] : 

ReadFromsScr : = TempStr 
End; ( ReadFromScr ) 


— Chr(Len); 


Procedure SetColor(F,B:Integer); 
Begin 
TextAttr :— F + B * 16; 
End; ( SetColor ] 


* 


Procedure Bcep; 
Begin 
Write(#7) 
End; { Beep } 
Procedure WriteManyCh(Ch: Char; X, Y,Num: Integer) 
egin > 
GAON LUS Y); 
R.AH: 
R.BL:= = TextAtir; 
- R.BBH:-0; .- 
R.AL;= = Ord(Ch); 
R.CX : = Num; 


„„ Intr($10,R) 
End; ( WriteManyCh D 
Procedure WriteSt(S: String; cjl: uc 


Begin 
GotoXY (c.l); 
Write(S) ; 
End; 


a GetCh(c): Integer) Char; 
Var 

Ch: Char; ` 
„Begin : 

Ke XCh < > #13 
i E. ud 
; PE C. 
Ch := XCh, ` 

XCh:- ABE: 

End ieu 
else Mic sa LAM E 


„Begin, ee 
- GotoXY (cl); ATE 
SE SR ] X UE 


if E ech > 232) and (Ord(Ch) < 127) TE 


then PutCh(Ch,c,l); 
GetCh:= Ch ^. 
End, (GetCh] ` 


{ setează culori ) 
( fond la B şi text la F | 
f TextAttr este în unit-ul DOS ) 


{ semnal sonor ) 


{scrie Num; caractere Ch pe ecran | ` 
{ începând cu poziţia X,Y 


( scrie şirul S pe ecran } = 
f incepând cu poziția cl) 


SI citește de la tastatură E) Ch ) 


A şi-l scrie pe ecran la coordonatele cl | 


zi daci este caracter. tipăribil JI 


ENS 


187 


dnte PutCh(Ch: Char; cl: Integer); 
Begin 
GotoXY(c,]); 
` Write(Ch) 
End; ( PuCh) * 


Mere ReadAKcy(Var Ch: Char; Var Fun 


Begin 
Ch : = ReadKey; 
If Ch « > 40 

then FunctKey : = 
else 
Begin 
FunctKey : = True; 
Ch := ReadKey 

> End; 

End; ( ReadAKey ] - 


- False 


Procedure MessageLine(M: String); 


Var 
S:Byte; 
. Begin 
r3 HideCursor; 
: - IfM < >” then Beep; 
, S: = TexAitr; 


Eie e E 


WriteStM,L25); . 
c En. 
CIrEol; i 
TextAttr :: := Š; 
ShowCursor SE 
End 1 MessageLine ) 


Procedure PickLine; 
„Begin ` 
. SaveAttr : = = jest Alea 
SetColor(White,Red); : 
WHGSUCSELECTARE | 
TextAur: = SaveAttr -- 
End; t PickLine Iu : 


Dioses Modiine;. 
— Begin 
. SaveAttr := DAE 
` SetColor(White. Red)... 
WriteSt( MODIFICARE 
/TextAlir : = SaveAur l 
End; (-ModiLinc ) Ee 


à Procedure BlankLine 
Begin 


188 ` 


{ scrie caracterul Ch pe poziţia c, 1 ) 


ctKey:Boolean); 


| citeşte o tastă, fără ecou ) 
{ FunctKey : = True dacă c tastă funcţională } 


e ' ` i + 


„ (afişează mesajul M pe linia 25 ) 


EUNT 


X S fiscala un mesaj explicativ ) 
Se pentru SELECTARE pe linia 24 d 


Ra- - Modiliare imp Esc= dee 10,24); 


SCC 


Ex H SE un mesaj explicativ | 
i pentru MODIFICARE pe linia 24 
Ret = Terminare modificare © y E n 25988 31310,24); 


t QM RS ^ i S d 
Ok Wu ae? SAN NEN x le 


| aligeazà spatii pe linia 24 ) 


WiriteSt( ^ ? ,10,24); e 
End; ( BlankLine ) E è 
Procedure ValidCh(Ins:Boolean; Ch,Tip:Char; XG,Y,Len: Integer; 
Var X : Integer); 

Var ( Validează caracterul citit Ch în } 
E:Boolean; ` { concordanţă cu tipul său, Tip ) 
TempSu : String; | 

Begin 
Case Tip of | 

T:E:= Chin [0.9]; 
R: E= Chin [0.9]; 
„else E:- True; : 
End; 
If not E 
then f 
Case Tip of 
x ES NM Sage ine Arade p permise: 0.9); - 
R: M a Permise 0. 3 si si paner); 
End 
else ; : 
Hepm o 5 = ` 
.MessageLine(); |. ;- 
then o or E D EE 
Begin ` EE 
TempStr — = Roggen Y XG Lee 23 ; SE 
SE EE EE 
GoToXY (xy); SE : e VS — SE Z 
Write(Ch); - OG oz cae IET n 
us zt 3 T , 
End; WEN ValidCh SE 


: Foncion EditField(XG, Y, Len: vue Tip co); E SECOLO i | 
Var E A S realizează SUO: unui câmp ecran ) 

„ ExitEdit : Boolean; E WA E pc LAAS QU rue de XG,YiLen] — 
'TCh: Char; OI ERO AI TAB ela n EEN „(side tip Tip j SE 


PD. T i : , : d 
ResStr,TempS String; Hi d coloana uid à cursorului gj 


X: Integer; Weis 
FunctKcy,InsT oggle : Boolean; 


Be 
E ucucte io | OU da 
OMNE UD S ca d Pose rcd 


` SaveAttr TextAur; QE UA. DA RENTE 
SeColor(ColorE2. ColorB2); 1 : CH Ce Xr „> (setare iv ug 

- Yt Tip in PPR!) ` Wu c e a numeric? | 

TempStr : = SPC(Le n). Vie aene ( da, se umple cu spatii | 

m^ H = Eent SEN ( citeşte din ecran ] | 

WriteSi(Tempstt X,Y), EAERI AES IRAT DS CES em 

KT eg i Kat ` $ 


ResStr : = TempStr; , 
InsToggle : = False; 
If XCh < > #13 
then ValidCh(InsToggle,XCh, Tip,XG,Y,Len, X); 
Repeat 
GoToXY(X,Y); 
If InsToggle 
then BigCursor 
else LineCursor; 
ReadAKey(TCh, FunctKey); 
If FunctKey 
then 
Case TCh of 
LeftArrow : X:= X- 1; 
RightArrow: X:— X + 1; 
InsertKey : InsToggle : — not InsToggle; 
SUR DeleteKey : Begin 


TempStr: = —ReadFromScr(X + 1 Y,XG + Len-X-1); 


WriteSt(TempStr +2? XY) 
: End; 
HomeKey :X:= XG; - 
EndKey :X:= XG+ Len-TL > 


else 
Case TCh of 
„ #32..#126, 


#128..#255 : ValidCh(InsToggle,TCh Tip.XG, Y, Len E 


EnterKey : ExitEdit : = True; 
"EscKey  : Begin 


WriteSt(RessStr, XG Ys 
ExitEdit : = True 
SEH E DE S 
BackSpKey : If x > -XG 
: then ^ 
.Begin 


A 


{ inserare sau suprapunere? 
( suprapunere: cursor mare 
( inserare: cursor linie 

{ citeşte un caracter 

4 tastă funcţională? 

( da 


( cursor stânga ) 
( cursor dreapta } 


( şterge de pe cursor ) 


( cursor la început 
( cursor la capăt 


CRAS 1 tastă nefunc(ionalá ) 


x ( caracter tipáribil ) 


( gata editarea ) 
( abandonează editarea | 


{ şterge stânga cursor } 


TempStr: = - ReadFromScr(% Y, XG tam); N 


- TempStr : = TempStr + 7; 
"Writest(Tempstr, X-1 Mec 
:X:=X-1; 
End 
- else Beep; 
„ CtriBackSp: Begin ` ` 
TempStr : = SPC(Len); 


WriteSt(TempStr,XG E 
ws E X:—XG a 
End; S SIT 
End; A qs AE 
Ié > XG + Len: al 
. then 
5 "Be 


egin 
X: - XG 4 * Len -1; 


( umple câmpul cu spaţii ) 


SE Sotal coloană cursor ) 


| a depăşit capătul zonei } ` 


| 
| 
| 
| 


Beep 
End; 


If X < XG then a depăşit în stânga î i 
SEH ( a depăşit în stânga începutul zonei ) 
X:- XG; 
Beep 
End; 
Until ExitEdit; i 
LineCursor; D 
TempStr : = ReadFromSer(XG,Y,Len); EAM 
TextAttr : = SaveAttr; 
WriteSt(TempStr, XG, Y); 
EditField : = TempStr; 
BlankLine; 
, XCh:- #13 
End; ( EditField ) 


{ procedurile Get... citesc din zona C,L si de lungime Len ...) 


Function GetStr(C,L,Len: Integer) : 206 Ge d. 
Begin. RE { şir de caractere } 
Gem = SCH ield(C, L Aen) 
End; ( GetStr ) 


er GetStrU(C, L,Len: Inge String; 
Var ; : i citeşte sir. de caractere. de e iati C,LLen ] 
S : String; s PARU M VLA m . {întoarce majuscule } 
E SE SE 7 | 
E E = GetStr(C,L;Len); Ge SE 
For I := 1 to Len do s[i] := = Upcasit); E 
WriteSt(S,C,L); — v. VERE MIA UNE 
GetStrU := S peer ed Aia atat AE See? 
End; ( GetStrU ) e EE 


Function Getlat(C,L,Len: Integer Im: E : 
S : String; a e aa ED Ve 2 SE 
d E: Boolean; ROUTIER E eue mr 
E T Integerz-0 9 WALLET VELIM TIE 
E: Beem - 
L^. Repeat. 
| ModiL 

(S: EditField(C, L i z f; 5 

StrToInt(S; Leni, E) ; SEL 

HE.” : i A BAe, 

then MessageLine(' " 

S else Mea Lin Caractere permise: 0. d 
Until E; $ 


Ze E eg g E 191 


«  Putnt(C,L,Len dru 
Getlnt := I 


End; { GetInt } 


ar 
S : String; 
E : Boolean; 
1: Integer; 
Begin 
Repeat 
ModiLine; 
S : = EditField(C,L,Len; T); 
StrTolnt(S,Len,I E); 
If E 
then Message linen 
else'MessageLine(^ Caractere permise: 0. ES SE? 
Until E; nid 
PutWord(C.L Len); Ades S EN DA e do 
GetWord : = EE SE 
End; { GetWord ) S SE 


Seege GetWord(C,L,Len:Integer) : Word; 


( întreg fără semn } 


Function GeILoni( CL Len inge): Loge ` a6 b; s 
Var i pico 0 E (întreg lung E 
S : String; A - EE EE 
SE Beleg 5 SE EE, 
ks Longint; As xc UU OI CC EUN i 
Begin: vd e TERES 
Répeat eu onc M eS SS S 
.  ModiLine; — Se ta CAN UR e 
Sx EditField(C,L, Len, p X EE E E 
StrToLong(S; Len, LE); | NEMUS. ive do So ON N SENE 
: "AES DAC GER SS em CS eu i 
then. MessageLine(") ` Rises 
else. Message Linc( Caractere permise: 0. 9) us 
Unil E; < E EAS ANNS ANER Ob T 
Pu-onă(C Len); voa esu cn EE SOR ENS 
- GetLong Red cere uM EE SS 
End; i GaWoid } SUE de 5t. A 


Lue 


G Re l Le De: Integer Real ` A OPEN RO e e 

pue Dg s " x SC (real cu Len cifre si De zecimale ) 

E E Oe UNS 

E Boolean; EE 
Seet EE 

Repeat eA Ce Cap EEN PS tratate RONS 

-~ ModiLine QC A AM Pa LCS i 

Sa E EditFicld(C,LLen, Rin RP AUD A E Se SAN 

StrToReal(S, Leo E); CORE D BNET 

It E- S : Í : 2 


- 


then MessageLine(”) 

else MessageLine('Caractere permise: 0,9, punct’); 
Until E; 
PutReal(C,L,Len, De,R); 
GetReal :  R 2 


End; ( GetReal ) 


(procedurile Ask afişează mesajul M pe poziţia ol şi.) 


„ Procedure Asklnt(M: String; cjl: Integer; Var]: integer); : 
Begin ( citeşte întreg pe 5 poziţii ) 
eer CL); A 
= i aus *Le M v^ 
End, {Askin} ngth( ) CG 


Procedure ask Word. String; ck integer ys I: Word); 
Begin im. citeşte întreg fără semn pe 5 poziţii ] 
WriteSt(M, C LL); K 


Le Gelln(C Length(M), L a 


„End; ( AskWord . | : i altei IER 
XA Function AskString(M: Suing ci lon: Integer): String | 
. Mar i ia o di e scerepe Len "redi 
S: String,” D ESENES S et S 
| -Begin Sees 
* WriteSt(M, CL). SUE Rin SERT AEN, 
E S GO Lengh(M) Len; IUDA CTUM ARE a 
1 ting:-$ ——. Yu ORDRES AN, eR ien 
E End; { AskSıring } ; : m o ET han do: 
Cé ui procedurile P Pu. o e pe Len vn boer ) 
d e 


Pr du Pu CL SE E EE 
See T = E Tee) 
Gett EE Ee 


p. Write(I:Len). 2x ua ENEE a Sd Maroc s dee e 
I8 NEE las "S j SML vn y NS E f e Ai X D ev 
ded Nó > A ES ` ; 
; Pur d Len:Inte gen Word) RAS RUEDAS RUN MT X 
Procedure or LA gen ho UNO ^s Pu 1: Datrsgul fil sema T). 
A GoToXY(C,L); Sa? Ee SE Von» T XY TN $ dn EN a SECH 
Write(ELen) . Bc os 
EE 
TÉ EN e EE ta d ` +» (întregul lung 1} 
E. Begin ` ? ^n e E A ; 3 "T i AUS M ` ; 21 N 
Ze „GoToXY(C,L); ` SA E EE 
eWrite(ELen)., ` d Tt EE g Ce 


; (Ph H f á 3 tul. ^i * uu ) Y à 
i (ër ] ke d i d \ 
i Ee uon). doy ea e fe APPEL di ARSE So N 
ES fi ue deck ox Y t 
SLOL Ma ` » 
EA i A A D 


D 


Procedure PutReal(C,L,Len,De: Integer R:Real); 
„Begin - 
GoToXY(C,L); 
Write(R:Len:De) 
End; ( PutReal ) 


( realul R cu De zecimale } 


H 


Begin ( Unit | i Seu 
XCh : = #13; | ( cod de iniţializare } 
SetColor(ColorF3, ColorB3) 

End. ( Unit ENG 


5.4. TAD UTILITARE 


Pe baza Operațiil implementate în UScreen « se pot congepe noi operaţii, utile in orice 
program ce posedă o interfaţă utilizator, care: 

= şterg o parte a ecranului: 

^. ClearZone(X1,Y1,X2,Y2: Integer); 
- comunică utilizatorului anumite mesaje: í 
: Message(M:String; C,L:Integer); ; 
„afişează stringul M începând cu. locația ecran (CL); 
. Pause | E 
afişează mesăjul: s i 


~ 


Hit any key to continue .. 


şi aşteaptă apăsarea u unei i taste; RIA Ae e etnie e Re 
- cer anumite răspunsuri standard. S 

i - Corect(c d: integer), Boao 

SS mesajul: 


„Corea (Rat - -Da) ix i DO ; ee 


: incepând cu locia ecran (c4) şi întoarce True dacă s-a apăsat literă D: sau pande 
Contin (cl: Integer; M String) : Ce 5 
; SE mesajul: , 


` a. 


e Am a z Continuati Me + Ra Da) xS i 
Ze N 
începând cu jo tăia ecran (€J) şi întoarce: True dacă s s-a apăsat litera '"D' sau RETURN; 
- Response(cl: Integer; M: String) : Quee zie : i 
„afişează mesajul EE 
Se oM n (DAN). 


j începând cu locaţia ecran: D s întoarce SITUE “dacă Sia apăsat litera 'D'. 
„= emit mesaje de éroare: deor . SA ca M 
- Err(M:String); ` > X 
"afișează mesajul M, aşteaptă apăsarea ünci taste şi opreşte programul. 
„verifică existenţa pe suporta unor fişiere specificate de utilizator: . 
 Exist(FN:String) : Boolean; 
Ántoarce True dacă inier) cu numele FN exi False altfel, 


N 


* 


Dora este dată în unit-ul Stuff, prezentat în continuare, care | 


Implementarea acestor o 
foloseşte unit-ul UScreen. 

ki , 

Unit Stuif; (TAD Utilitare) 


INTERFACE 


Function Corect(c]: l:Integer) ` Boolean; 
Function Contin(c,l:Integer; M:String) : Boolean; 
Procedure ClearZone(X1,Y1,X2. „Y2ilnteger); ` 
Procedure Message(M: String; CL: Integer); ` : : 
Function Responsé(M: String; C 2,L:Integer) : ERO. : ie pu s 
Procedure Pause; EE EE ; ; 
Procedure Err(M: String); : S ; S 

. Function Exist(FN: String) : SCHER ; 


IMPLEMENTATION e A RD me i 
Pese UE. A oue e Marc ed că e + 


; "Var NUR WE enn SS G ; ; H ` $ M 
- LàstC, LastL : Lies Mee RE e ec age e ES „A ultima linie sí coloană } 
| LastM : String; E pp S e US "pee care s-a scris mesajul LastM ) 
= ee vM EN 
; Procedure Gezei? yı X2 YŠ zue), 
` Var NS zona mamen e QO,Y2) E 
HideCursor; EE 
For]: = Yi'to Y2 Do: M RARE D CM PEE UE 
- Begin ` ` Tuae. 4 cot 
GoToXY(Xi, J); 4 E SE 
For I := X1 to x21 Do Viet "e SE 
End; - D » 
ShowCursór 
End; ( ClearZoné IS 


t dams er Boolean; E i cu c COPIE B o 
Function Cores (c t g ): GE zr UN s 2 {cere confirmarea corectitudinii ] - 


Se =J extAllr; KE a GC [A A ex ox i VR ; i : S n 
SerColor(Black, White); í E d SE | . 
n ^ WriteSt('Corect (Ret = Da). wo rU ial a SE 
Bh e ReadKey; i | t MOERS AME 

D Text: m S; : d ue TR TE 
^ Writest — cl); VAI NO EA : Mua 
L "Corect := Ghin ['D' SCH Zo Se E : X 

DU End; S pner) : 235 AU SER SUN S 


Zi | 1 , 5 i j i e ^x E e ` E jt 1 j în 195 x 1 


"Ys 


tata Contin(c,l:Integer; M:String) : Boolcan; 
ar 


a { cere confirmarea continuării ) 
S : Byte; ; ` ; 


Ki 


Ch : Char; 


Ste TextAttr; : * 
SetColor(Black, White); 
WriteSt('Continuati ? +M +? (Ret Da) oral PRE 
Ch := ReadKey; 
Text Autr : = S; 
ClearZone(c,l,c + Length(M) +20,1); 
Contin : = Ch in ['D';'d',*13] 

End; { Contin } 


Procedure Mossage(M: Gier XLinteger); - . ^ 
„Var S 1 afişează au. M, stergánd pe WEE sica Te 


4 


» ve 


Pate eine Last Lengha- Gate iy ; e 

- $:- TextAttr; - ; zm : SESS A 
SetColo(BlackWhit); —^ 7 7 - ^ ACE 
WriteSt(M,C,L); PD IRR RT Ed SEXCINS 

: TextAutr : =S; EE SE 


E : e E Inte er SE XS AN : 
É ; n: X: afigeazàá insebused M s d cere confirmare Te 


Ss : 
E^ m aoo P SC 
A Until Chi in [D'; HE S | E È t : 
Message(”, CE 2 x À 
nse := C i "s 
Er C NS ` RES SA 


«0h: C har; uod [REL AN AN QM ere * E S EH 
Zum any key to continue y ` HARS A RN A SE Ge EE 
Ch: ReadKcy WE E CR ERIS MSN S E Ee 


3 ; În Mus acestora, mai sunt definite încă patru operaţii: primi 


HE Err(M:String); | de 


B f D 
d RE e» { afişează mesajul de eroare M şi opreşte programul 
Pause; 
Halt ` 
End; ( Err ) 


Function Exist(FN:String) : Boolean; | 
is SES zx A prim True dacă fişierul cu numele FN există 
: File; b : „n {preluat din US RON TP 6.0 


Schi eat) SE EE 2 | 


Eee (usi Y » IU NES oos e 7 (eod deininalizare |. - 


End. (Unit Sut} EE 


5.5. TAD VIDÈOFORMAT - pt p e 


Posedăm acum SEET necesare. pai implementarea’ unui generator d 
` videoformate. Conceptual, un`videoformat va ocupa ua octan, SE lui fiind formată din: 
`- numărul de câmpuri (Nil ie ia Di RU A e 
-+ — definițiile câmpurilor. : UM 
Un cámp al videoformatului va fi definit de. WENT atribute: ; 
`> — titlul sau explicația câmpului. (Title, string) — SS or 
` =- coordonatele începutului titlului (coloana XT, linia YT, zeg SE 
- tipul câmpului (Tip, caracter, vezi UScreen) -` E EM a $ 
- coordona ele zonei de: ER toate ue intregi ` e 
CliniaecranYD; E Na e cat oe WERE i 
coloana de teput Di EE E IN cai eat ge S RANAN 
„ coloana de d ie XDF. EE SES 


à " 
St 


- ini(ializarea colo ata nuMe) 
- declararea Moria Nu d o tbe ee SQ MERS GS 

- afişar. videoformat ui (RésetMenu); - NEN 
- Geess? unui câmp din videoformat  PickSub Menu, zeit ` ^ 


S 'cámp selectat (SerCoord). 
- stabilirea atributelor unui câmp ( ele două realizează afişarea pe ecran 


: recae proiectate sunt: 


i 


ururi dubla - 
dreptunghiulare (cutii, "box'-uri), cu frontiera linie simplă (SBorder) sau S 
E quei ur dintre; iaca două EH afişeăză iar a doua şterge cursorul bară (ce va ireprézenta | | 
Er selectat; EE cu aie, atribüte : zonà de dale a E & numite ShowBarCursor, : ; 


respectiv DeleteBarCursor. 

Uzual, se poate lucra la un moment dat 
parcurse urmează succesiunea lopicüt 
- iniţializare; 

- declarare; 

- afişare; 

- selectare; 

- citire/afişare/editare câmp. 


cu un singur videoformat, Btapele care trebule 


i - lnijializarea videoformatului setează pe'0 numărul de câmpuri ale acestula, Declararea 
videoformatului înseamnă de fapt declararea fiecărui câmp al acestuia, specificándu-se numltrul 
câmpului si toate atributele din definiţia acestuia, Se recomandă ca un videoformat să fie declarat 
într-o procedurădestinatăspecialacestui scop, Alişareavideoformatului înscumnă afişarea titlului 
pentru fiecare câmp, în zonele prevăzute. | 
Câmpul curent din videoformat este iluminat cu ajutorul unui cursor bară, Stabilirea 
câmpului curent din videoformat se face cu ajutorul tastelor funcţionale: , 


HOME  — salt la primul câmp; 
END - salt'la ultimul câmp; ` 
SĂGEATĂ SUS - câmpul precedent; | 
SĂGEATĂ JOS +  -câmpulurmător (in ultimele două situaţii, parcurgerea este circulură, 
în sensul că Succ(NumPicks) =1 şi Pred(1) = Numpicks), iar 
~ | selectarea unui câmp presupune în prealabil stabilirea lui 


3 drept câmp curent și- apoi apăsarea tastei RETURN. 


Terminarea lucrului cu videoformatul se face prin apăsarea tastei ESC. Funcţiile 
PickSubMenu(First,Last), respectiv PickMenu vor întoarcenumărul câmpului selectat (la apăsarea 
lui RETURN) sau 0 (la apăsarea lui ESC). Funcţia PickSubMenu permite accesarea unui grup 
de câmpuri consecutive din videoformat, începând cu First şi terminând cu Last, iar PickMenu 

Š Se 2 de fapt PickSubmenu(1, NumPicks). : , ? í 


După ce un câmp a, fost selectat (se cunoaşte numărul lui), prin SetCoord se pot 
determina atributele acestuia (tipul şi coordonatele zonei de date). Folosind, operaţiile 
. implementate în unit-ul UScreen, se poate realiza toată gama de funcţii enumerate (citire, afișare, 
- editare). În mod obişnuit, lucrul cu astfel de videoformaic într-un program utilizator presupune 
proiectarea de proceduri pentru: — ATA SOM 
$ - declararea videoformatului; ` — A deeg 
- citirea secvenţială (câmp cu câmp) a datelor din videoformat; 
- afişarea datelor dinvideoformat; ; =- 
-- modificarea selectivă a unor câmpuri. X A 
ER aul E ce nis Ge 
Implemejitarea operaţiilor: proprii TAD Videoformat sc găseşte în unit-ul UMenu, 


P. 


prezentat în continuate, Se observă masiva folosire a operaţiilor din UScreen. 


E 


VIN 1 


Unit UMenu; Pe NA ACD MS S PERS {TAD Videoformat} 


H " 
Ki 


"INTERFACE ee AR SN RON urs, 
| P ocedure Border X1,Y1,X2,Y2:Integer; HeaderString `; e 
1 Procedüre SBordet(X1,Y1,X2, Y2:Inteper; HeadersString; ` ^ 
/. . PROCEDURE DefineFicld(FieldNo, YT, XT:Integer; 


* “Tiule:String, YD,XDI,XDF:Integes ` SN IM an 
E. „ Typ:Char); : ^ TOSS 
B $ H k ` Li 


198 . ro | n beth: NS | 4 


Procedure ResetMenu; 

Procedure ShowBarCursor(P.: Integer); 
Procedure DeleteBarCursor(P : Integer); 
Function PickSubMenu(First,Last:Byte) : Integer; 
Function PickMenu : Integer; 

Procedure SetCoord(P:Integer; Var XY, Len: Integer; Var T: Ghar) 
Procedure InitMenu; 


y 


IMPLEMENTATION 4 
Uses 
UString, UScreen,Crt SE 
Const ; RAE pie 
. MaxSciFields = 40; . . i ( numărul maxim de câmpuri ) 
Field E Record ` ` Y a ES. i „4 descrierea unui câmp ) 
Pis e VEEN * i e (ie gi Coloană explicaţie | 
N IND, 03» 2 ` { linie zonă de editare ) 
ES OXDLE EE oui zonă de editare, in coloane | 
XDE: Integer; 
Typ : Char; ; ROME AE R- real = întreg, C= şir de caractere }- 
Title ; Sang, PATE RU ADEM - { explicaţie câmp i g 
` End; i ; QU e E WU I ADI EMPTIS 
Var i ke SH H ^ z ai á îi L 5; - " d R Tu AS ; 
Pik 5 o o E DEL UY e AED E a p IV ( câmpul curent ]- 
E LastPicld- ; EE E { ultimul câmp şelectat } 
NumPicks : Integer; ; Daae es Diener de câmpuri } 
ScreenMenu : Arráy[1. MaxsorFieids of ron E 
| SaveAttr: Byte; d. LO d UL STUDI AREE SC atribut gene | 
Procedure Border souz E Header: dun e sa = 
Maro a t trasează un ug cu chenar dublu şi titlul Header: ) 
I: Integer; - de cc c AD MY De 
Be VU LUN e oa 


egin 
PutCh( XL YD; ; 
WriteManyCh(=,X1 + 1 Ka Lea es 
PutCh(3',X2,Y1); - 
Eor I: = = Y1+1to Yi Do. 


PUCH pes UV Ke PO DUM AE M MAE 
Puce XOU C NE ce e ci A 


sert Ma | zo ld dc ate de 
WriteManyCh( XL e1Y2X2XI- ES i SE E ded 
PutCh( XAYZ), 3 VOS n S x 

If Header >’ Sn Ek Ai a ae | 

then S : 

+ Header + e XL Qo-X) du. Ee a um 

e Tineri alte div E 4 i í 

End; { Border ky ; 


ocedure SBorder(x1, Y1,X2,Y2:Integer; Header:String); 
(trasează un dreptunghi cu chenar simplu d titlul Header } 


I : Integer; 
- Begin 
PutChC r PXLYD; 
rite anyCh(' —X1+1 Ni ,X2-X1- 1 y 
PutCh(4 ,X2,Y1); i 
For 1 := Y1-- 1t0 Y2-1 Do 
Begin ` 
PutCh( | X11); N e Dër 
Puch. GR à 
End; 
PutCh( € x Ke 
WriteManyCh(—,X1 + 1 Max 4) 
PutCh(" ' KSC X i RET 
If Header > then, ` ^ * 
` WriteStC- >+ Header +°}, xi * (X2-X1) div 2- 
((Length(Header) E 1) div 2), YU; 
End; d SBorder } 


| 'ROCEDURE DefineField(FieldNo, YT, XT: ingen. 
^. Title:String; YD, XDI, XDF: leen 


Typ:Char); LE l 
: "S ec deco u un nou câmp al i videcformatubi ) 
s WË ue > NumPicks then Ino(NumPieks); 
ScreenMenu[FieldNo]. YT : = XT. M OU NOUS Ve SES AL exu 
ScreenMenu[FieldNo].XT : = = XT; A 3 SE EES 
. A ScreenMenu|FieldNo].Title : := Title; EE 
ScreenMenu[FieldNo.YD:- YD;. ee ir Na 


|"... ScreenMenu[FieldNo].XDI : EXDE (o 99 UNS SANI UNA 
5 ScreenMenu|[FieldNo].XDF := mr QUAM. cc EU AERE EE 

we e FD» ; VEN A Seve SR e ala 

d; 


Procedure ResetMenu; i EE EE EE Se 
Begin - SE TAN m „+ ( reafigeazá pe ecran videoformatul ) ` 
B SaveAttr : = TexAttr; Son eMe UAE E PEN 


| SetColor(ColorF3,ColorB3); ` D = 
ClScr; - bor DE EU 
3 For Pick: = 1 to NumPicks Do) © ^ 5 ^ 5000 
„ With ScreenMenufPick] Do e 
4 Wrtest(Tille X TYT); c: a oC ON ee! 
- TextAttr : SE EE EE Ee 
: End; ( ResetMenu } ` QUIAE SA NN ENDS 


Procedure: ShowBarCursor(P : deg zi Kë 


TempStr : String, EN 


Nis] M ANE EE 


$y 


„Begin . 3. : 
I SaveAttr : - TexAt se DON S ; 
„ SetColor(ColorF2, Ss EE E GE 


With SereenMenulP] Do 
Begin 
TempStr : = ReadFromScr XDI, YD, XDF-XDI 4-1); 
EE, YD) ; Ak 
nd; ! 
TextAttr : = SaveAttr ' 
End; ( ShowBarCursor ) 


Procedure DeleteBarCursor(P : Integer); j : je 
Var ETEA ER "4 şterge cursorul bar? 
TempStr: String; e cm ei | 
Begin ` ` SE 
SaveAttr : = = TextAttr; x e j 
„ SetColor(ColorF3, ColorB3); - : 
With ScreenMenu[P] Do : i 
Begin $ ERO. 
“TempStr : = Resdprnmser (Dl, YD XDF-XDI +) sea iat 
-WriteSt(TempSur, XDI XD): SS 
End; VER UEM ncc ta Noe do oo o SA 
TTextAur:- SaveAttr ` 7 B m E eco. e Er 
„End; 1 DeleteBarCursor d S ; das E I AR 
CMS PickSubMeny(First L Last: Bjte): as X ; 
Var bx selectează cu by funcţionale un cám 


Ch: Chár; ; EE „A întoarce numărul câmpului sáu 0 la ieşirt 
E PickExit : "Boolean; Scion: GE Sr? i (ar pium circular câmpurile " 
| : FunctKey : Boolean; - Ws pios Și SAC es CS NOT > 4 dintre First si Las 


Begin... SY Set EE HAST) 
SavcAttr:— Team EE SE "eene alribüte culoare ecra' 
PickLine; + `- EE d : Auf afişare, mesaj explicati 
PickExit ;= CR RUN ; 
Pick ; = Suce(Pick); 
1f (Pick > Last) or (Pick. e 1n UA 
then Pick ¿= First; = EE 
| ShowBarCursor(Pick); Sd : d 
Repeat ^ s : 
HideCursor; ` i 
LastPick : = Pick; NONIS 
,, ReadAKey(Ch, Dee 
KI not Tags 
Ss then + 
Case Ch of i 
“EnterKey, o E RE 
EscKev, EE E à 
332.5 126, 2 
ee #128,,#255 : mn: = True; N 
Else. Bee ak 2 i bres paie crow Ea Ve 
GAP ARENE D une ey SIS eih LO d i m OO S : 
Eu. Ge 2000 ud SEPA ada iN 
pod TATUM i Picks Pick- d NITE 


t stabilire câmp curen, 


SSC citeşte o tast ^ 


E tastă nefuneționă 
CH sire din selectare. câm 


v udi enis di 
„ve minor în XC LE 


A : 


{ câmpul precede: 
SONS N Sa 


. 


. Function PickMenu Integer; . 


2 3 Procedure InitMenu; S 25: 


` ` Toten 2 
-. End. ( Unit UMenu) 


DA noi. Pick := Pick + 1: 
.HomeKey : Pick := First; 


EndKey : Pick: = Last; 
Else Beep; 
End; ( Case FunctKey ) 
If Pick > Last then Pick : = First; 
If Pick « First then Pick : — Last: 
If Pick < > LastPick 
then 
Begin 
DeleteBarCursor(LastPick); 
ShowBarCursor(Pick) ^" — 
End; Ss 
Until PickExit; 
DeleteBarCursor(Pick); 
If Ch = EscKey. 
then PickSubMenu := 0 
else 


'Begin pot 


PickSubMenu : = Pick; 
XCh := Eh 
End: à 

ShowCursor; 


a TextAttr:=  SaveAütr. gms 


End; 1 PickSubMenu Je 


LN 


Beem ` 


Procedure SerCoord@: Integer: ER X, X, Len: Integer; 2i 
z ar T:C ; j 


EE 1 
* Begin 
"With EE ds 


Len: = | XDF-XDI + i 
SEN cap 


Ser T SetCoord} 


Begin . ; PIE 
NümPicks : Se EE 
(XCh := #13 Se Gs 

„End; "iech SE 


org 


N^ 
2x A ' Í 


( câmpul următor 

{ primul câmp 

{ ultimul câmp 

1 semnal sonor: tastă nepermisă 
{ parcurgere circulară } 


{ gestiune cursor bară } 


4 A ry 
EE SL { şterge cursorul bară ). 


5 {abandon selectare ) 
4 selectare OK ) 


CA aire cursor editare ) 
E refacere atribute culoare } 


s 


i selectează c cu EE functionale un câmp ) 


` ` PickMenu:- page, auno) p UM 
End; ( PickMenu } Us EE 


ER SE 


"ës 


` ( eod de inigializare } 


5.6. TAD MENIU PULL-DOWN 


,  O manieră uzuală de concepere a aplicaţiilor interactive apelează la meniuri pentru 
realizarea interfetelor utilizator. Folosind TAD descrise mai sus, se poate proiecta si implementa 
un TAD Meniu Pull-Down cu minimum de efort, 

Un astfel de meniu afişează opţiunile posibile într-o "cutie" una sub alta, iar selectarea 
unei opţiuni se poate face fie cu ajutorul tastelor funcţionale (săgeți sus/jos, HOME, END) + 
RETURN fie prin apăsarea unei litere ("shortcut-key" sau “hot: -key" sau prescurtare, ce apare în 
denumirea opțiunii cu alte àtribute decât textul acesteia), în cazul nostru prima literă din 
denumirea opțiunii. Cu modificări minore, se poate realiza un meniu în care prescurtarea să fie 
orice literă din titlu. Gen un meniu pull-down va ocupa un ecran, structura lui fiind 
formată din: i 
— poziția colpului din stânga sus a "cutiei" meniului nos Os) Şi Se cutiei 
(Longest), întregi; 
- numărul de opţiuni (NumPicks, întreg); 
XN. - denumirile optiunilor (MenuMsg, tablou de şiruri de caractere); 
- - prescurtările opţiunilor (MenuLtr,. tablou de caractere), 
S Operatüle proiectate sunt: . 
„= pentru declararea RS 
` Procedure SetMenuBox(X, Dane MenustrString); ! 
E stabileste XPos : = X Sai 
YPos := * inu : i 
- MenuStr conţine denumirile opțiunilor, separate prin ca serena] Ms baleind MenuStr, 
se construiesc tablourile MenuSír si MenuLtr, se determină numărul de opţiuni 
NumPicks. şi lungimea maximă a ge cat " unei opunni Longest; s 
- pentru afigarea meniului: SS S 
Procedure ResetBox; ` ^ I Ms E Ee 4 
e afişează pe ecran "cutia" meniului şi opţiunile acestuia how 
- pentru selectarea unei opțiuni din meniu: 3 MES CAS - 
Function PickMenuBox : Char; ` RS 7 ; 
3 - permite stabilirea, opțiunii dorite cu ajutorul E funcţionale. (săgeți sus/jos, - 
y . . HOME, END) : $i selectarea, acesteia cu RETURN, întorcând caracterul ce 
4 reprezintă prescurtarea opțiunii selectate; N ` 
- la apăsarea tastei, ESC î întoarce caracterul NUL (40). à 


: “Implementarea TAD Meniu Pull-Down se găseşte în unit-ul MenuBox, EEN din TOP 
ŞI modificat de autori. Se folosesc tie UScreen. E HR zs 


Y 


Unit MenuBox; uS d o co (TAD Meniu Puli Down) 


“Interface LAS. : 
Procedure ResetBox; ^: 
Procedure SetMenuBox(X,Y : Gab Menustr : String); 
Function PickMenuBox: Char; as 


Za t e CS E CO 


B V DI mental on » ^ DE 
< Uses U Screen, UMenu,Crt,Dos; Yl 
|. Const MODUS 
e Mau en 15; A | 


4 


, Var : | : 
Yu XPos,YPos : Integer; 
MenuMsg : Array[1..MaxMenultems] of String; 


{ coordonate "cutie" stânga sus ) 


text 
Menulir : Array[1. -MaxMenultems] of Char; —- : í "hot iy | 
NumPicks : Integer; A { număr opţiuni | 
Pick : Integer; i ; ( opțiunea curentă ) 
LastPick : Integer; ; { opțiunea precedentă } 
Longest : Integer; 3 ; roh ( lățime maximă "cutie" ) 


SaveAttr ` Byte; { atribute de culoare text şi fond ) 
Procedure ResetBox; 
Var : 


P : Int i oe Ge ne ccran mitul ) 
: Integer; , 


SaveAttr : = TexiAur; NIA. 

SetColor(ColorF4, ColorB4); : 
< ə SBorder(XPos, YPosXPos + Longest + 3 YPos + Nunick +1 ex 
- For P:= 1 to NumPicks do 

Begin A UU E 

FillChar(MenuMsg[P, Length(MenuMsg|P) + 4b DICE DE T E 

Lomgest-Lengh(MenuMsg]P]; fi Lo 
MenuMsg[P,0] : = Chr(Longest); e S - SE : M 
SÉtColor(ColorF1,ColorB1); . i e LE at 
WriteSt( °? + MenuMsg[P] +” „XPos +1 YPos- + P 
SetColor(ColorF2,ColorB2); X SE e 
E robs VE ME DE TA e 


End; : E SH 
TexAur: = SaveAttr; - dE dx. e EH 


Zb Y S 
Wi 


EPIO cda e SetMenuBox xy: Inte er; WË nt E 
i iz : ee { mcis meniul cu Ss S; XPos: i-XYPos Y 


"Var X i în S opțiunile sė- separă prin "/^ | 

EU A re Em GE i us oc ER pume literă devine "hot-key" | 
“Begin ; Y. ; "( NumPicks se determină | 
XPos:- X Z t jaa se S em LES 


A— ————  —— — Na 


~ - à 
um | 
I umPicks < Viseul am: then. NumPicks dé : = 

rr Len: =s Pos(/,Copy(MenuSir, SE + Cr) i : | 
A UY. MenuMsg[NumPicks] : =-Copy(MenuStr,CPos Len) ` + 
A esr OpCas EE DE | GE SE 
SH e. If Length(MenuMsg[NümPicks]) > Longest : ESAMI | 
; p F then Longest : = e EEN aia! 
; CEU Ur CELER En M VO UD EN UE | 
í . f 7 d "Ty ŞI DA Ae: ; 3 a ARN d SAN 4 p 
"T vii i f ) s 


ResetBox; 


End; ( SetMepuBox ) { afişează pe ecran meniul ) 
Function PickMenuBox : Char; ; ( 
Marino ue "A selectează o opțiune din meniu 
mu LM i { întoarce "hot-key" la selectare 
: Kar, #01 
PickExit : Boolean; sl a abandon cu ESC 
BeepOn ` ` Boolean; x 
FunctKey. : Boolean; 
SaveAttr := TextAttr; | AUN UN cal dree text 
HideCursor; | ERAS RCM SEE (s „ {ascundere cursor editare 
SetColor(ColorF3, ColorB3); : E cursor bară pe opţiunea gu 
.— WriteSt( se ER NA] v: viet 
^^ Repeat 
ReadAKey(Ch, FunctKey); TUM 5 A SAID legie o astă 
E oops d id PUE V M a, (o. {tastă 
ceu o ua o e 
*32.)05: Begin o 005 ERUNT ibil "hot- Ce 
BeepOn: = True; Ce ere EE > 
'For II : = 1toNumPicksdo ` Was un ai RN duod, 
E SÉ EE 
EECH e ate OK ) 
ES Pick : = II; a aci LE: 


PickExit : by E ues E SE 
BeepOn : = False ERA : 
„End p 7. 


E E d ue 
ARS nd; SIS 
EnterKey,EscKey: Dee Tre rom os 
. End; Pe (care p DRONK CS 2n 


dam) ` 


SC SH | da 


E x ; MES a CRISE SEEN ecu iie] ; 
-CaseChof i S 
UpArrow- : Pick := S "ee, e pend precedentà e 
|  DownArrow: Pick := ZER 
E ; Else Beep, o. n ` (tas nepermisà 


"M Pick - NumPicks then pie o To e „larger crea) 
- If Pick < reata SEH EE | 
SG SE T dct: 5; Se e DN Se Ne opiu scias) 


D 


j d out 4 A H 

c l FL,ColorB1); IPSINS SA | 

H eit borgo d pr MA ei mea vai); 
EE Ee a S 


. PutCh(MenuLtr LastPick à ast Pick); 
Sak Color) iU p uit), 
ritest( ^ + MenuMsy]Pi Js s+ Pick); 
LS ( NE El Pick] +>’, XPos + 1, YPos + Pick); 
: End; , 
Until PickExit; 
If Ch = EscKey SEN 
then PickMenuBox : = #0 


P abando 
else PickMenuBox: = MenuLur( Pick]; ( dent OK | 
SE AL ' [ afişare cursor editare | 

E = SaveAutr; ° zl refacere atribute te 
GEN 3 { refacere atribute text ) 


End. ( unit MenuBox | 


A 5.7. TOOLBOX-UL INTERFAȚĂ UTILIZATOR (TIU) 


În secţiunile anterioare am prezentat considera(üle de proiectare şi implementarea unor 

TAD care se constituie într-un toolbox, deosebit de util în proiectarea si realizarea interfetelor 

- > utilizator. Componentele acestui toolbox sunt gencralc, nefiind legate în nici un fel de o anume 
„aplicaţie concretă. Din punctul de vedere ál icrarhici unit-urilor componente, TIU prezintă 
următoarea diagramă de structură: . . S ; i 


Feng 


š z 1 


i 


În această diagramă legăturile sunt de la dreapta la stânga şi de jos în sus. Se observă cá unit-ul 
Se 2 j : AUN zog 125 . E Tow : ] S 
— — Liste nu apare în această diagramă, ct fiind independent. Ee 


we 
SE 


ESO. În general, dimensiunea fiecărui unit este rezonabilă. Am încercat să realizám TAD cu 
^ * . functi bine precizate, care pot fi folosite ele însele în aplicaţii, dar, în acelaşi timp, servesc. la 
“realizarea de noi. TAD mai complexe. În cazul TIU, un exemplu de TAD complex este 
-Videoformat (unit-ul UMenu) . > - e le 


D 
CES 


Răspunsul la întrebarea "pentru ce să se proiecteze un asemenea TOOLBOX? este 
2E — simplu: reutilizarea codului şi extensibilitate. Chiar în realizarea TI U putem vorbi de reutilizarea 
. . —codului, prin densa folosire a operaţiilor din unit-urile sale componente în implementarea de noi 
— Gperaţii. Gradul de reutilizare va creşte în următoarele nivele, pe care cititorul le poate. concepe. 

Pe de altă parte, ntodularitatea face ca fiecare componentă a TIU si TIU în ansamblul său să ie 
sisteme deschise; la nivelul fiecărui TAD se pot concepe şi implementa noi operaţii şi, de 
asemenea, în TIU.se pot adăuga noi FAD. e 


z R EA Dee Se RT i qu d S 

“În conceperea unċi aplicații, TIU furnizează "primul nivel de operaţii. În mod normal, 
= mai trebuie proiectate cel puţin încătrei nivele: "rr Ch ; ; 
< ^. -+ TAD pentru gestiunea datelor (de gen Storuble_Object); SS "EU 


`- TAD pentru realizarea prelucrărilor specifice aplicaţiei; ' 
, 5j ` | Y jS SEM A 


| 


- programele aplicaţiei. 


Multe dintre mediile de programare sau suprafețele de operare (Turbo sau Borland 


| Pascal, Turbo sau Borland C, C++ "Windows, ctc.) posedă colecții de implementări de TAD 


|pentru realizarea interfejelor utilizat 


interfetelor utilizator. 
| 
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| SE | Aet Gs CAPITOLUL 6 
CURE UE Pct RE NE EN Vara aa DTE rama eg ma pa A RU DI E tea a a - $ 


ÎN LOC DE CONCLUZII 


PS Am prezentat capitolele anterioare metodele clasice si moderne de programare 
descrise în literatura de specialitate, Sunt cunoscute lucrări care prezintă paradigmele programării 
[Flo79, Gri85, Mey88], proverbe ale programării [Led75] sau alte reguli privind disciplina 

rogramürii. Dăm în continuare mai multe metode, principii și reguli pe care le considerăm a fi. 

. importante în activitatea de elaborare a programelor, Vom indica sursa bibliograficá acolo unde 
este cazul, iar unde nu, lé considerăm ca făcând parte din folclor. 


"Do Not Break the Rules 
- “before Learning them" 
Ledgard [Led75]. 


- 1. Defineste. complet problema [Led75 si Gris]. 
S Li vi MSS Pe SN 4 . SE a 


. Această indicație pare fără sens pentru unii cititori. Dar ea este foarte importantă. Nu - 
>œ se poate rezolva o problemă dacă nu se cunoaște această problemă. „Aşa cum s-a arătat ín 
à secţiunea 1.3, specificarea corectă şi completă a problemei nu este o sarcină trivi.:lă, ci una foarte 
importantă si adeseori chiar dificilă. — DUM e M MA aaa > S S 


52: Gândeşte mai întăi, programează pe urmă [Led75). + 3 


3 Íncepánd cu scrierea specificaţiilor problemei, trebuie pusă în prim plan gândirea. Este 
- specificatia problemei corectă? Dacă da care ar fi metoda de rezolvare? Dacă există mai multe 
` metode de rezolvare, care ar fi cea mai potrivită scopului urmărit? Este algoritmul proiectat 


D 


.3. Foloseşte programarea Top-Down [Led75] — ^s s EE o 


`. (Rafinarea în paşi succesivi [Sch90]) ee, 
(Divide et impera [Gri85]), e Soo 


- . Acestmod de programare a fost deseris pe ut în secțiunea 1.5 Pus ore de primul 
-rând despre descompunerea unei probleme’ în subprobleme mai simple, dar si de împărțiri 
SCH două si aplicarea separată a procedeului utilizat pentru cele două submultimi de date. 
^ Pe acest principiu este construit algoritmul” QUICKSORT pentru ordonarea crescătoare a 
5 20 RES Sp : 2 Xi Xn. ECH SET E Ee ge 


SN 


x 2 (DAE Dona A AAA Zo ie f EE Ka EE iți lea toate aumarele din ; 
“Procedeul folosit constă în a duce numărul; pe o anumită poziție pa d ci alsori 
„Proeedeul he mai mici decátx, și toate cele din dreapta, mai mari Se va aplica acelaşi algoritm 
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D 
Objinem următorul subalporitm, care sortează secvenţa de numere l 
d « 
LÀ 
in ordirie crescătoare: Xy Xa png 


Subalgoritinul QUICKSORT(s,d) este: 
Cheamă SPLIT(s,d,i); 
Dacă s «i-1 atunci Cheamă QUICKSORT(si-1); — , 


Dacă i-- 1« datunci Cheamă OUICKS QUE NA 
« — . sf QUICKSORT QUICKSORT(i 4 D $ 


unde subalgoritmul SPLIT este următorul: 
vereinen SPLIT(s,d,i) este: ` 
Schimbă termeni în secvenţa x,, x, , 4, ... Xa aducán iji i 
încât toţi termenii Xp cu p< : sux o odd x SX, AUN RA. 
E şi toţi termenii x, cu p > i sunt în relaţia xx ) 
Fie 2x; i-s;j-d; k "Ml i 
Repetă + SOWEIT : 5 
Cáttimp (i<j si vsx) execută j: =j-1 sf cát 
EE 
up 1«j şi X;2 V) execută i; =i + 1sf cát 
(IK AE OR SCH a 
EE 
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4. Folosește şi alte metode de proiectare: OREL seta PI E H 
bottom-up si mixtă [Led75]. — 4 NE LE 

Metodele.de programare referite au fost prezentate în secțiunea 1.5. Ambele metode. 

încurajează într-o oarecare măsură reutilizarea (discutată în 2.2.3), reducând costul realizării 
: programelor. De asemenea, folosirea unor componente existente. (deci testate) măreşte gradul ` 
.. de fiabilitate a produselor soft realizate şi scurtează perioada de realizare a acestora. : 

`, 5. Foloseşte subalgoritmii existenți si tehnica programării modulare [Led75]. 

` Tehnica progrămării modulare a fost prezentată în secţiunea 1.6, iar principiile 

` modularizárii au fost expuse în 2.2.2. Evident, dacă o parte din subalgoritmii necesari programului 

~ sunt deja scrisi şi verificaţi, viteza de lucru va creşte prin folosirea lor. Foloseşte deci bibliotecile 

- de componente reutilizabile existente şi construieşte singur astfel de biblioteci, care să igglobeze 

[Led75] se subliniază cá o bună programare modulară elimină legăturile prin date 

- comune între două module (principiul legăturilor minime, expus în 2.2.2). Se recomandă ca 

fiecare modul să realizeze o activitate bine definită şi independentă de alt modul. Comunicarea 


între două module trebuie să se realizeze numai prin mecanismul parametrilor formali-actuali. 


Ps 


EA e Foloseşte proiectarea orientată pe obiecte [Coa91]. a 


Metodele tradiţionale de proiectare a produselor program (top-down, bottom-up, mixtă) 


" | t H 
Zu d E he" 2 (EA) à 
z i ` X 


mu sunt adecvate pentru faza de întreţinere a acestor produse, deoarece ele produc arhitecturi 
rigide şi extrem de vulnerabile la schimbările ce se petrec în domeniul problemei pe care 
programul o rezolvă). Dintre tehnicile cunoscute, orientarea pe-obiecte (descrisă în capitolul 4) 
răspunde cel mai bine la cerința privind realizarea de produse flexibile, ușor de modificat. 
Aşa cum am arătat în 2.2.3, prin folosirea ierarhiilor de clase în bibliotecile de componente se 
obţine o reutilizare masivă, în sensul că îmbogățirea ierarhiei nu afectează aplicaţiile ce folosesc 
respectivele componente reutilizabile. 


DH 


7. Elaborează documentaţia programului în paralel cu realizarea lui [Led75]. 


Aşa cum s-a arătat în mai multe locuri din acest material, pe durata de viaţă a unui 
program se iau mai multe decizii. E bine ca aceste decizii să rămână consemnate împreună cu 
rezultatul final al fiecărei faze din viaja programului (specificarea problemei, proiectarea 
algoritmilor, programul propriu-zis, datele de test folosite). Vor rezulta documentaţii de analiză, 
proiectare, implementare şi exploatare. Primele trei sunt necesare la întreţinerea aplicaţiei, 
trebuind a fi actualizate ori de tâte ori se produc modificări, iar ultima este necesară celor care, 
„exploatează aplicaţia. Pe lângă acestea, un program bun va trebui să posede și o componentă de 
asistenţă on-line (funcţie help), care contribuie la asigurarea a ceea ce am numit interfaţă 
prietenoasă. 


8. Amână pe mai târziu detaliile nesemnificative. 11 

Această regulă stabileşte priorităţile de realizare a componentelor unui program. În 
primul rând se acordă atenţie aspecteloresenţiale. Prin urmare, este inutil să se piardă timp cu 
scrierea unor părți de program pentru tipărirea rezultatelor şi a constata ulterior că rezultatele 
nu sunt folositoare. Scopul principal al oricărui program este de a obţine rezultate corecte! 


9. Detaliile nesemnificative sunt semnificative. [Sch90, Led75, Murphy]. x 


E Beneficiarii (in foarte mult la forma rezultatelor şi, adeseori, judecă programatorii după 
această formă. E păcat de munca depusă dacátipárirea rezultatelor lasă o impresie proastă asupra 
beneficiarului. Îți dorim, cititorule, să poti să dai si alte exemple. 


10. Consideră orice tip structurat la nivel abstract. 


Această regulă se adresează proiectantului, forțându-l să gândească mai general şi 
- îndepărtându-l- de, contextul în care apare respectivul tip structurat. Ea reprezintă esența 
proiectării dirijate de operaţii, când funcţiile unui program se obţin cu ajutorul operaţiilor TAD . 
proiectate (sau. existente deja). Considérarea TD independentă de contextul de aplicare are efecte 


benefice în ceea ce priveşte. obţinerea unei imagini generale a acestuia şi oferă eficienţă şi 


A m 


simplitate, prin aceea că se consideră împreună reprezentarea şi operaţiile respectivei structuri 
de date. Mai mult, proiectarea şi testarea algoritmilor pentru operaţii se va face mai rapid şi mai, 
corect. i ; ) . 4: ~ ; VR ` HS - S 

Abordarea sugerată mai are un avantaj: TAD este un sistem deschis, în sensul că oricând 
se pot adăuga noi operaţii, fără ca operayile existente să se modifice. Mai mult, se pot modifica 
algoritmii acestor operații, fără ca progtamele care le apelează să se modifice. Importanţa acestei 
reguli creşte în contextul orientării pe obiecte, clasele nefiind altceva decâtimplementări de TAD. 
În această situaţie, ierarhia de clase se poate u Tae 
claselor existente deja, şi care nu influenţează programele clienţi. 


e 


îmbogăţi cu noi membri, obt inuti prin specializarea 


11. Proiectează obligatoriu operaţii de intrare-ieşire pentru fiecare TAD; 


s Aceste operaţii sunt extrem de utile la testare, d 
când pentru intrări-ieşiri se folosesc videoformate, este recomandată recuruerea la o interfaţă 
utilizator standardizată, existentă în biblioteca de componente reutilizabile (de exemplu un TAD 

Videoformat, de genul celui exemplifica în 5,5 sau Turbo Vision în mediile fitmei Borland) 
Folosind reutilizarea, proiectarea si implementarea acestor operaţii sc face rapid, 


ar nu numai, În cazul cel mai general, 


12, Proiectează structurat algoritmii [Led75], 


. , Aceastărregulă, specifică iniţial programării în Fortran, 

în orice limbaj. Ca regulă generală se cere conceperea algoritmului într-un limbaj Pseudocod şi 

, Dumai după aceeea codificarea algoritmului într-un limbaj de programare, De remarcat ideca că 
descrierea algoritmului nu trebuie să facă referință la un limbuj de programare particular, 


se poate aplica la programarea 


13, Verifică valoarea variabilei imediat după obţinerea acesteia, 


, , Dacăo variabilă întreagă ia valori într-un subdomeniu e, e verifică valoarea variabilei. 
Orice ieşire din acest domeniu indică o eroare care trebuie înlăturată. Valoarea variabilei poate 
B calculată sau introdusă de utilizator. În primul caz, verificarea trebuie făcută după calcul, în al 
doilea caz se recomandă ca verificarea să urmeze imediat după citirea valorii respectivei variabile. 


14, Evità instrucțiunile GOTO [Led75]. 


E bine cunoscută controversa GOTO [Knu74a]. Există păreri pro [Knu74a] şi contra 

[Dij68] folosirii acestei instrucțiuni, Limbajul Fortran avea nevoie de această instrucţiune, neavând 

implementate în limbaj structurile de calcul specifice programării structurate (la ora respectivă 

era în vigoare standardul FORTRAN IV din 1966). Recomandám folosirea disciplinată (apel de 

sus în jos) a instrucţiunii GOTO doar în situaţia în care limbajul de implementare nu posedă 
structurile de control elementare, , SĂ s 


15. Nu recalcula limitele şi nu modifica variabila de ciclare în interiorul unei structuri 
repetitive dată prin propoziţia Pseudocod PENTRU [Led75]. 


O astfel de practică poate duce la erori greu de detectat şi încalcă regulile programării 
structurate. Atunci când este necesárá schimbarea variabilei de ciclare se recomandă folosirea 
uncia din structurile repetitive REPETĂ sau CÎTTIMP. ; 


- 16. Nu ieşi forțat din corpul unei structuri repetitive redată prin propoziția Pseudocod 
„PENTRU, WE N | 

- Instrucţiunea Pseudocod PENTRU corespunde. unui număr SUR de utut: 

“ale corpului ciclului. În. situaţia când corpul conţine şi testarea condiţiei de contin are 

a cichini, recomandăm a ee folosi structurile PENTRU sau CATTIMP , şi nu PENTRU. 


e 


17, Evită arficille[Led75]. i 


Prin folosirea artificiilor în programare, a prescurtărilor și simplificărilor se pierde adesea 

din claritatea programului și uneori sc ajunge chiar la introducerea unor erori. În plus se pet. 

"ajunge la situaţia când programul obținut nu poate fi transportat pe un alt sistem de calcul, deci 
se pierde portabilitatea programului, ` : i ; | 


by 


4 e LÁ. 


9 23 Am. a D D D .. AI D ^ 
reg insà Situaţii în care prin anumite artificii se câştigă eficienţă în execuţie sau se face 
„economie de memorie. Dacă acest fapt este important atunci artificiile sunt binevenite, în caz 
contrar nu se recomandă folosirea lor. 


18. Folosește constante simbolice. 


Ee Recomandăm folosirea intensivă a constantelor simbolice, oriunde în textul sursă trebuie 
să scrieţi un număr (lă declararea tablourilor, la precizarea limitelor de variaţie a unor variabile, 
etc.). Argumentul trebuie căutat tot într-o lege a lui Murphy; 


Mărimile constante trebuie considerate variabile, 


Prin utilizarea acestor constante se mărește gradul de generalitate a textului scris, iar în situaţia 
în care valoarea lor trebuie schimbată, modificarea respectivă implică numai definiţia constantei, 


` 19, Foloseşte TD cu nume (in loc.de TD anonime) la declararea variabilelor, 


Folosirea notaţiilor este proprie limbajului matematic, Putem considera că declararea 
unui nou tip de date cu nume este o nota[ie, care concentrează în numele tipului toate 
proprietăţile acestuia. Folosirea acestor notații creşte gradul de înțelegere şi de modificabilitate 
pentru textul sursă: schimbând notația, toate referirile la nume capătă noul înţeles, 


20. Nu folosi variabile neiniţializate [Led75]. 


O eroare foarte frecventă a programatorilor începători (dar nu numai a lor), constă în 
faptul că uită să iniţializeze variabilele. Destule compilatoare permit acest lucru, neverificând dacă 
o variabilă a fost iniţializată înaintea folosirii ei. Alte compilatoare ini(ializeazá automat variabilele 
numerice cu valoarea zero. Cu toate acestea ny e bine să né bazăm pe o asemenea inifializare ci 

* — së atribuim singuri valorile iniţiale corespunzătoare variabilelor. 
4 Acest principiu capătă o mai mare importanţă când variabilele sunt pointeri. Durata de 
viaţă a variabilelor dinamice referită de pointeri (adică timpul cât ele sunt alocate în memoria 
dinamică) este controlată de programator. 
j ; ` 


: .. 21. Foloseşte comentariile in textul sursă [Led75]- - s 


: J - 

Uitarea "e scrisă-n legile omenești” şi acționează asupra fiecăruia dintre noi. E greu de 
descifrat programul'unei.persoane dacă el nu e însoţit de nici o explicaţie, Aproape la fel de greu 
este să descifrăm propriul program scris în urmă cu mai multe luni de zile, În secţiunea 1.12 am 
subliniat importanţa comentariilor şi ce-ar trebui să conţină ele. Încheiem subliniind că ele pot 
furniza o foarte bună autodocumentare a programului. Afirmația de mai sus este valabilă când 

, textul sursă al unui produs este disponibil. n situaţia unor aplicaţii de mai mare anvergură, când 
programatorii clienţi utilizează module scrise de programatorii furnizori (2.2.2), modulele furnizor 
- trebuie să posede o bună documentare a interfeţelor pe care le au. 


22. Verifică corectitudinea algoritmului " programului in fiecare etapă a elaborării lor 
[Gri85 şi Schü, S 


; y EASY Se Ge? NS 
Detectarea şi eliminarea unei erori imediat după comiterea ei duce la creşterea vitezei 

„de realizare a produsului, evitándu-se activităţi inutile de depanare, În plus erorile semnalate în 
j timpul testării sunt adeseori greu de descoperitsi, câteodată, imposibil de eliminat altfel decât prin 
| rescrierea modulului sau programului respectiv, SĂ 


f: 


d } 
j 
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entru punerea imediată în practică a acestei reguli, sugerăm următoarea reformulare: 


Testează fiecare subprogram imediat după ce l-ai scris (codificat). 


i Ai de codd e Ce setas codificárii bottom-up şi sugerează o abordare sistematică 
a i [ acá pentru proiectare se pot folosi oricare dintre metodele indicate 
în codificare (si testarea aferentă codificárii), abordarea de jos în sus este esenţială. Regula de mai 
sus se referă numai la subprogramele nou concepute. Sugerăm ca această testare să se facă, pe 
cât este posibil, independent de programul în care se va apela respectivul subprogram. Este 
adevărat că activitatea de testare (conceperea unui program de test) poate să necesite un oarecare 
timp, dar ea este benefică cel puţin din trei puncte de vedere: : 

- scoate în evidenţă erorile provocate de proiectarea algoritmului sau codificarea 

.. nmeadecvatá a acestuia în respectivul subprogram; 

- facilitează detectarea erorilor, deoarece dimensiunea problemei este mai mică; în fapt 
nu se pierde timp cu'scrierea unui program de test, ci se câştigă timp, deoarece 
la fiecare nivel de detaliere (vezi 4.3.5.6) se vor folosi numai componente testate 
deja; ceea ce rámáné de testat la nivelul respectiv este gestiunea corectă a 

apelurilor respectivelor componente; 

- obligă implementatorul să gândească încă o utilizare (cel puţin) a respectivului 

t subprogram, independentă de cea pentru care a fost iniţial conceput, în acest fel, 
se face un prim pas spre generalizarea respectivului algoritm sau subprogram. 


23. Foloseşte denumiri sugestive pentru identificatorii folosiţi în program [Led75]. 


. Fiecare identificator (nume de variabilá, de tip de date, de constante, de subprograme) 
îşi are rolul şi semnificaţia lui într-un program. E bine ca denumirea să reflecte această 
semnificaţie, mărind astfel claritatea textului programului. 

Regula prezentată este o generalizare celei date in-[Led75], care se referă numai la 
variabile.  - 


24. Foloseşte variabile auxiliare numai acolo unde este strict necesar |Gri85]. 


Fiecare variabilă trebuie să aibă o semnificație proprie, iar în demonstrarea corecti- 
tudinii programului, acesteia i se ațaşează un invariant, care trebuie verificat. > 

Folosirea necontrolată a mai multor variabile auxiliare, ruperea unor expresii chiar lungi 
în subexpresii cu diferite denumiri, pot duce la reducerea clarităţii programului. 


$ E > 
25. Declară local toate variabilele auxiliare dintr-un subprogram- 
CS Această regulă are efecte benefice în ceea ce priveşie autonomia modulului reprezentat 
de respectivul subprogram. Se obțin astfel cel puţin următoarele avantaje: — 
- testarea respectivului subprogram este mai uşoară; - d 
- subprogramul este mai general (apelarea lui nu presupune declararea unor variabile cu nume 
. prestabilite în programul apelant); t à : 
- execuţia subprogramului nu afectează mediul programului apelant (nu vor exista efecte 
secundare), micşorând apariţia erorilor în acesta din urmă. 


26. Folosește cu grijă metodele de transmitere a parametrilor ce sunt implementate în 
limbaj. ` 


„ În principiu, există două clase de astfel de metode de transmitere: prin valoare şi prin 


D 
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adresă (referinţă). Transmiterea prin valoare nu modifică valoarea parametrului în programul 
apelant după ce apelul a fost executat (chiar dacă acesta este modificat în corpul subprogramului 
apelat), fiind adecvată pentru parametrii de intrare (care numai aduc înformaţie) în subprogram. 
În această situaţie, fiecare parametru formal transmis prin valoare este tratat ca o variabilă locală 
. în respectivul subprogram care, la începutul execuţiei subprogramului este iniţializat cu valoarea 
parametrului actual. Transmiterea prin referință presupune lucrul cu informaţie de adresă, caz 
în care parameltul formal (din subprogram) si cel actual (din programul apelant) vor avea aceeaşi 
adresă de memorie. Prin urmare, orice modificare asupra parametrului în subprogram va rămâne 
şi după ce respectivul subprogram s-a terminat. Această metodă este recomandată pentru 
parametrii de ieşire sau pentr cei micşti (care sunt şi de intrare si de ieşire). De asemenea, 
transmiterea prin referință se recomandă pentru parametrii de intrare cu dimensiune mare a 
reprezentării, în ideea economiei de memorie. În acest ultim caz, se recomandă atenţie sporită 
în manipularea acestora. . 


27. Prin scriere redă cât mai fidel structura programului [Led75]- 


Importanța indentării şi spaţierii:pentru claritatea programului au fost arătate ín 
secţiunea 1.4, Fiecare programator trebuie să aibă propriile reguli de scriere, care să scoată cât 
mai bine în evidenţă structura programului și funcțiile fiecărei părţi a acestuia. 


28. Nu uita să testezi programul chiar dacă ai demonstrat corectitudinea lui [Sch90]. 


Sunt cunoscute demonstrații greşite pentru unele teoreme celebre din matematică. Şi o 
demonstraţie a corectitudinii unui program poate fi greşită [Mi179]. Dar, chiar dacă demonstrarea 
corectitudinii algoritmului este: validă, programul poate conţine greşeli de codificare, de 
- introducere (tastare) sau pot fi alte cauze care generează erori. 


+ 29. Foloseşte facilităţile de depanare şi de verificare a aserţiunilor din program [Led75, 
Gri85). pop e. 


Despre depanarea programelor. s-a- discutat în secţiunea 1.9. Unele compilatoare 
construiesc secvenţe de instrucţiuni care verificá.valoarea de adevăr a aserţiunilor inserate. în 
program, însă cele mai multe nu iau în considerare aceste aserţiuni, scrise sub. formă- de 
comentarii. Ar fi foarte util ca orice situaţie in câre aceste aserţiuni nu se verifică să fie semnalată 
programatorului. În acest scop se recomandă ca pe timpul punerii la punct a programului să se 
insereze instrucţiuni care la neverificarea aserţiunilor să tipărească valoarea curentă a variabilelor 
care intervin, precum şi locul în program în care s-a întâmplat acest lucru. Dacă programul a fost 
- testat, aceste instruc[iuni-de tipărire condiţionată pot fi înlăturate. , : 

Regula de mai sus se poate extinde in forma urmátoare: 


Verifică toate precondiţiile in subprogram. 


Am arătat în 3.2.2 că există operaţii (subprograme) totale şi parțiale, ultimele furnizând rezultat 

corect numai dacă parametrii de intrare verifică precondiţiile. Există două strategii de verificare 

a precondiţiilor: în programul apelant sau în programul apelat. Regula precizată mai sus stabileşte 
că a doua'strategie este corectă, cel puţin din următoarele considerente: `: 

- textul sursă necesar pentru verificarea precondiţiilor se scrie o singură dată; ` ` 2 

= subprogramul funcţionează corect si în cazul unui apel cu parametri necorespunzătari; 

- sarcina programatorului client este mai simplă, el putându-se preocupa de problema 

la care are nevoie de respectivul subprogram, şi nu de funcţionarea corectă a 


acestuia din urmă; 
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- sẹ face un pas important în asigurarea robusteţei produselor realizate (erorile detectate 
Bu nu se propagă la alte nivele, fiind tratate acolo unde apar, adică în subprogram), 
„Regula de mai sus are efecte atât în faza de proiectare a algoritmilor (va trebui ca prin 


DM unor parametri de tip boolean să fic transmisă în afară informaţia privind verificarea 
precondiţiilor), cât si în cea de codificare (textul sursă va conţine verificarea în cauză), Pentru 


vip iei sugerám cititorului să consulte proiectareași implementarea TAD Tablou Ordonat 
în 5.1. | 


30. Asigură portabilitatea programului, evitând să foloseşti specificul calculatorului 
[Led75]. 

Portabilitatea este una din calităţile importante ale unui program, mai ales când acesta 
are un caracter comercial. Ea nu poate fi asigurată dacă programatorul foloseşte în textul sursă 
instrucțiuni specifice unei implementări particulare a limbajului de programare pe un anumit 
calculator, care diferă de standardul existent (de jure).sau acceptat (de facto) de comunitatea 
informaticienilor, De aceea se recomandă folosirea variantelor standard ale instrucţiunilor unui 
limbaj de programare. Părţile care depind de calculatorul folosit, deobicei legate de instrucţiunile 
de intrare-iesire, de cele grafice, dar şi de alte situaţii specifice, e bine să fie izolate în module care 
vor fi rescrise la trecerea pe alt calculator, fără a afecta celelalte module, ` 

Ca exemple de astfel de abordări, menţionăm: biblioteca de subprograme ştiinţifice a 
firmei IBM (cunoscută sub numele de SSP, de la Scientific Subroutine Package), şi sistemul de - 
operare UNIX. SSP este scrisă în FORTRAN IV (iniţial) şi nu conţine instrucţiuni de intrare- 
ieşire, Sistemul de operare UNIX este scris în limbajul de programare "C", cunoscut pentru 
portabilitatea lui, în proporţie de peste 90%, iàr partea dependentă de maşină este separată în 
module distincte, Ce vor trebui scrise în limbajul de asamblare al calculatorului gazdă. 


S „31, Atenţie la atribuirea simultană ! 


Atragem atenţia că atribuirea simultană nu este echivalentă cu o succesiune de atribuiri. 
De exemplu, atribuiréa: ^. > : 


"(xy2:-xr2y43) s ă (1) 
da 


nu este echivalentă cu atribuirile l ts ^ 


xis. 3 mS 
vis Kit EE po e (2) 
zi-yt3. e MD , 
Dacă înaintea efectuării lor vectorul (%,y,z) avea valoarea, (5,5,5), după atribuirea simultană (1) 
vectorul va primi valoarea (1,7,8), în timp ce după atribuirile (2) el va avea valoarea aaa 
(1,3,6). Există puţine limbaje de programare în care sunt permise atribuiri simultane, Regula d 
mai sus se referă la limbajele de proiectare a algoritmilor, unde sunt permise asemenea atribuiri. 


32. Acordă atenţie deosebită lucrului cu pointeri : V 


G r H " P ANLE YN C dtes Y itándpro. ato- 
Folosireavariabilelor pointer máreste flexibilitatea unui program, permijandprogramat 

rului să gestioneze alocarea ees variabilelor dinamice referite de acestea, Pentru pre 

variabilă pointer p, de tipul ^ TPdeclaratá în subprogramul SP, trebuie să se țină cont că (în cele 


ază vom folosi notații Pascal): ` RUE IA 
ai dci * UN p d fi pia ca o variabilă locală imsubprogramul SP, Bind gestionată cu 


D Val 


* 


ajutorul stivei de execuţie: este alocată în stivă la apelul lui SP din programul 
apelant P si este dealocată imediat după ce execuţia lui SP se fücheie şi se revine 
în P; prin urmare, durata de viaţă a variabilei p coincide cu intervalul de eu de 
execuţie in care > subprogramul SP este activ; 


- variabila dinamică p ^este de tipul TP; ea va fi alocată la întâlnirea unui apel al 


procedurii standard New(p). (care alocă în memoria dinamică spaţiul necesar, 

, dedimensiune SizeOf(TP) şi atribuie pointerului p ca valoare adresa respectivei 
zone) si va fi dealocată cu Dispose(p) (care eliberează din memoria dinamică 
spaţiul'o ocupat de p ^si distruge valoarea pointerului p); prin urmare durata ei 
de viaţă este intervalul dintre aceste um apeluri de proceduri standard, Pc 
neapărat î în această ordine. ` 


Din considerentele de mai sus rezultă că: A a 
- orice referire a. variabilei dinamice p “trebuie să se facă în intervalul de instrucțiuni 


dinire New vsi Dispose; ` DE 


= în cazul când peste folosită numai în SP, regula de mai sus este suficientă, cu 
precizarea cá apelul Dispose(p) trebuie sá à facă parte din corpul de instrucțiuni — 


al subprogramului SP; 


- dacă se dorește ca p ^sá existe şi după ce execuția subprogramului SP s-a terminat, 


acest lucru presupune următoarele acţiuni: 
- in (sub)programul apelant P se va declara o variabilă q de tipul, ^ TPrare va 
ME fi globalá'in SP; 


in schimb o atribuire de forma q := p; (în q se va păstra a adresa 


.. variabilei dinamice p ^ prin urmare va fi verificată egalitatea p ^= gis 
'.pointerul. q este. necesar deoarece ` la terminarea execuţiei E 
. Subprogramului SP pointerul } p, local în SP, va fi automat dealocat şi - 
- adresa variabilei dinamice p s-ar. pierde; această rămânând ME 


: "dar neputând à fi referită); . 

- MUS variabilei dinamice notată Sen sus p ^se va face în d prin q "Grind. 
* în-vedere atribuirea q : — p; făcută în SP; 
ae dealocarea variabilei dinamice notată mai sus s p^ "se va face i in P prin 
AT iue pe ca e CAEDE 


in Seul subprogramului SP va lipsi dealocarea prin Dispose(p), făcându-se E 
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10 porunci din concluziile lucrării 


1. Defineşte complet problema 
2. Proiectează structurat algoritmii 
“3: Foloseşte algoritmii existenți şi 
tehnica programării modulare 
4. Foloseşte proiectarea orientată pe 
obs te 
5. Gândeşte mai întâi, programeazá pe 
urmă 
6. Detaliile nesemnificative sunt semni- 
ficative 
. Foloseşte comentariile în textul sursă 
. Asigură portabilitatea programului, 
evitând să foloseşti specificul calcula- 
torului 
9. Verifică corectitudinea algoritmului şi a 
programului in fiecare etapă a 
elaborării 
10. Elaborează documentația programului 


Editura PROMEDIA 


OO N 


Pret 3990 LEI ISBN 973-96114-9-4 


